div72 has quit [Remote host closed the connection]
div72 has joined #bitcoin-core-dev
bitdex has quit [Ping timeout: 240 seconds]
bitdex has joined #bitcoin-core-dev
Guest58 has joined #bitcoin-core-dev
Guest58 has quit [Client Quit]
brunoerg has quit [Ping timeout: 258 seconds]
sudoforge has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
ronoaldo has quit [Quit: Konversation terminated!]
brunoerg has quit [Ping timeout: 244 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
<bitcoin-git>
[bitcoin] 1440000bytes closed pull request #25236: wallet: use vector instead of list for transactions (master...listtx-memory) https://github.com/bitcoin/bitcoin/pull/25236
brunoerg has joined #bitcoin-core-dev
z9z0b3t1c has joined #bitcoin-core-dev
z9z0b3t1_ has quit [Ping timeout: 250 seconds]
szkl has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
bairen has quit [Ping timeout: 240 seconds]
bairen has joined #bitcoin-core-dev
mikehu44 has joined #bitcoin-core-dev
Saloframes has quit [Quit: Leaving]
brunoerg has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
jarthur has joined #bitcoin-core-dev
Saloframes has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
bfsfhkacjzgcytf9 has quit [Ping timeout: 255 seconds]
szkl has quit [Quit: Connection closed for inactivity]
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
dougefish has quit [Read error: Connection reset by peer]
dougefish has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
jarthur_ has quit [Quit: jarthur_]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<laanwj>
div72: how do you even get a foreign key into that function? i don't think it's considered an issue because afaik, that function is only used for loading wallets, and it only supports the keys generated by bitcoin core itself
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #25241: [23.x] rpc: Capture potentially large UniValue by ref for rpcdoccheck (23.x...2205-uni-no-copy-π) https://github.com/bitcoin/bitcoin/pull/25241
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #25242: [22.x] rpc: Capture potentially large UniValue by ref for rpcdoccheck (22.x...2205-uni-no-copy-π) https://github.com/bitcoin/bitcoin/pull/25242
<hebasto>
theStack: II've tested the master branch at 0be1dc1f56f611bebb4204a3f3221f425f156bcf, and it does not seem that #20640 changed behavior. Not being a wallet expert, I'm afraid I just failed to create the right testing transaction. Do you have an example of a tx which fires the `WalletModel::AmountWithFeeExceedsBalance` error (pre-20640)?
<gribble>
https://github.com/bitcoin/bitcoin/issues/20640 | wallet, refactor: return out-params of CreateTransaction() as optional struct by theStack Β· Pull Request #20640 Β· bitcoin/bitcoin Β· GitHub
<bitcoin-git>
[bitcoin] fanquake opened pull request #25244: build: pass bdb cppflags only where needed (master...use_bdb_cppflags_needed) https://github.com/bitcoin/bitcoin/pull/25244
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #25245: refactor: Remove no-op TIME_INIT on deser (master...2205-no-time-deser-π) https://github.com/bitcoin/bitcoin/pull/25245
donor has quit [Ping timeout: 250 seconds]
brunoerg has quit [Ping timeout: 240 seconds]
<bitcoin-git>
[bitcoin] fanquake opened pull request #25246: Revert "build: more robustly check for fcf-protection support" (master...remove_clang_7_note) https://github.com/bitcoin/bitcoin/pull/25246
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 255 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 244 seconds]
jonatack has joined #bitcoin-core-dev
vasild has joined #bitcoin-core-dev
bairen has quit [Remote host closed the connection]
bairen has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 258 seconds]
vasild has quit [Ping timeout: 240 seconds]
erwanor has joined #bitcoin-core-dev
<erwanor>
Hey, I've been trying to find a design doc summarizing the different binary wallet formats / compatibility graph but so far no dice. Does anyone have a lead? if there isn't one, I'll try to write it myself (if you can point me to important release tags I should look at, that'd be extra cool!)
<sipa>
there are two database formats (bdb and sqlite), and two type ways to encode "the set of watched addresses" in a wallet (legacy and descriptor). Old wallets are bdb/legacy, new wallets are sqlite/descriptor.
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
vasild has joined #bitcoin-core-dev
ronoaldo has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 272 seconds]
<bitcoin-git>
[gui] hebasto opened pull request #611: test, refactor: Use the same shutdown path as in bitcoin-qt binary (master...220530-exec2) https://github.com/bitcoin-core/gui/pull/611
<hebasto>
bytes1440000: could you post your exact steps in a pr comment?
<bytes1440000>
Sure
<hebasto>
ty
bytes1440000 has left #bitcoin-core-dev [#bitcoin-core-dev]
ronoaldo has joined #bitcoin-core-dev
Guest6727 has joined #bitcoin-core-dev
Guest6727 has quit [Client Quit]
ronoaldo has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
ronoaldo has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
<luke-jr>
23.0 just isn't the version for release notes. I messed up and put Core's 23.0 notes in Knots instead >_<
ronoaldo has quit [Ping timeout: 256 seconds]
z9z0b3t1c has quit [Remote host closed the connection]
<theStack>
hebasto: Thanks for taking a look! To my understanding, the error should be thrown if coin selection / fee calculation fails due to not having enough funds to cover the fees (if "fSubtractFeeFromAmount" is not set). The simplest transaction I can think of is one that simply spends _all_ funds of a wallet. Not sure though if the GUI is allowing that, maybe there is no possibility and throwing `AmountWithFeeExceedsBalance` was already dead code b
<theStack>
efore #20640 was merged.
<gribble>
https://github.com/bitcoin/bitcoin/issues/20640 | wallet, refactor: return out-params of CreateTransaction() as optional struct by theStack Β· Pull Request #20640 Β· bitcoin/bitcoin Β· GitHub
mikehu44 has quit [Ping timeout: 246 seconds]
<theStack>
b10c: (RE BIP324 link) That seems to be very useful, thanks! Indeed I wasn't aware that there is a dedicated webpage for BIP324
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #25248: refactor: Add LIFETIMEBOUND / -Wdangling-gsl to Assert() (master...2205-assert-lifetime-π) https://github.com/bitcoin/bitcoin/pull/25248
<bitcoin-git>
bitcoin/master e93046c Daniela Brozzoni: MOVEONLY: Move signrawtransactionwithwallet test
<bitcoin-git>
bitcoin/master e895900 Daniela Brozzoni: test: Use MiniWallet in rpc_rawtransaction.py
<bitcoin-git>
bitcoin/master 269fa66 MacroFake: Merge bitcoin/bitcoin#25044: test: Use MiniWallet in rpc_rawtransaction.py
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #25044: test: Use MiniWallet in rpc_rawtransaction.py (master...test_rawtransaction_miniwallet) https://github.com/bitcoin/bitcoin/pull/25044
sipsorcery has joined #bitcoin-core-dev
<div72>
laanwj: You're right, I've encountered the issue in a downstream where OpenSSL was still being used. The chances of this affecting Bitcoin is pretty slim as a wallet from a 7y old version which needs to be compiled with a pre 3 recent OpenSSL version is needed.
<div72>
That's why I've come to ask instead of just making a PR.
brunoerg has quit [Remote host closed the connection]
furszy has quit [Ping timeout: 240 seconds]
furszy has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<DavidBakin>
so that means someone with such a wallet can't in fact use a newer bitcoin core to read it?
brunoerg has quit [Ping timeout: 240 seconds]
<sipa>
it's not clear to me whether this is an issue for the bitcoin core codebase at all (includin historical versions)
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #25250: [22.x] test: replace hashlib.ripemd160 with an own implementation (22.x...2205-backport-ripemd160-π₯) https://github.com/bitcoin/bitcoin/pull/25250
<sipa>
there are certainly DER private key encodings that are valid but bitcoin core today wouldn't be able to parse, as it doesn't have a full DER parser
<sipa>
but i believe that no version of bitcoin core (including very old ones) would emit such encodings
<div72>
I am not sure on the exact conditions which can cause this, but pre-libsecp256k1 uses i2d_ECPrivateKey which can.
<sipa>
Well, it didn't happen with Bitcoin Core versions from 2014 linked against OpenSSL from 2014 and before.
<sipa>
And Bitcoin Core from back then cannot be used unmodified against today's OpenSSL's versions.
evanlinjin_ has joined #bitcoin-core-dev
<div72>
Fair point.
Kaizen_Kintsugi_ has quit [Ping timeout: 276 seconds]
sudoforge has joined #bitcoin-core-dev
<laanwj>
"This repository contains Python scripts for allele-specific mapping. They were used to map ATAC-seq, RNA-seq and Hi-C reads in a mouse" heh apparently there's another "asmap" project on github with a quite different purpose
<sipa>
Sorry, I'm not good at naming things.
<sipa>
;(
<laanwj>
it would be hard to confuse them!
<sipa>
I recently discovered that the code we were using to gather BGP dumps to extract ASN mapping data from was accessing the archive using "latest" file names rather than date-based ones.
<sipa>
Now, some of the collectors in the archive have been offline for a while.
<sipa>
Which meant that those "latest" dumps were in some cases from 2004.
<sipa>
Dropping those reduced the resulting compressed asmap file size by 300 kB.
<theStack>
bip324 question about handshake: in older slides (from breaking bitcoin 2019) i saw it was proposed that only odd pubkeys (i.e. starting with 0x03) are allowed, but the current BIP states only even pubkeys (i.e. starting with 0x02) are. any specific reason for this change?
<sipa>
the latest spec we're working on used elligator squared pubkeys, which are 64 byte uniform
<sipa>
but that may not be published yet
brunoerg has joined #bitcoin-core-dev
<theStack>
sipa: thanks, good to know. that explains why there are PRs around implementing elligator squared pubkeys (both in secp256k1 and bitcoin core), but no mention of it in the (obviously outdated) spec i read
brunoerg has quit [Ping timeout: 240 seconds]
ronoaldo has quit [Quit: Konversation terminated!]
ronoaldo has joined #bitcoin-core-dev
ronoaldo has quit [Client Quit]
bitcoinboi has joined #bitcoin-core-dev
ronoaldo has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
<sipa>
@theStack So elligator square is an encoding for public keys that encodes points as 64-byte, but *every* 64 byte sequence corresponds to a point, and the encoder picks a random one. So the result is that you get bytes that are indistinguishable from uniform.
<theStack>
sipa: so if i understand this correctly, we want the p2p-v2 handshake messages to look like an uniform byte string in order to disguise the fact that a (ecdh) handshake is happening in the first place?
<sipa>
exactly!
<theStack>
wouldn't an observer still have a high chance of concluding this by the fact that the messages have exactly 64 bytes in size?
<sipa>
well after that the rest of the protocol follows, which also sends bytes indistinguishable from uniform
<sipa>
there may be some information that can be inferred from timing and tcp boundaries
<sipa>
but tcp doesn't have a concept of messages per se
bomb-on has joined #bitcoin-core-dev
___nick___ has joined #bitcoin-core-dev
donor has joined #bitcoin-core-dev
<theStack>
right. though i'd assume that in a packet analyzer (like tcpdump or wireshark) one would see the initial pubkeys as messages of 64 bytes (given that we an observation spot both routes from A->B and B->A pass through), no?
Guyver2 has joined #bitcoin-core-dev
<theStack>
(if not, then nevermind, i heave to read up on tcp/ip again :D)
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
<sipa>
you'd see a 64 byte message in one direction, then a 64+N message in the other direction (because it'll be a concatenation of the ECDH response + the next part of the protocol that follows)
<bitcoin-git>
[gui] hebasto opened pull request #612: refactor: Drop unused `QFrame`s in `SendCoinsEntry` (master...220530-sendcoins) https://github.com/bitcoin-core/gui/pull/612
<laanwj>
sipa: oops, good find, yes it's good to have a smaller file and i doubt that including data from 2004 was at all helpful
donor has quit [Ping timeout: 258 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 260 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
brunoerg has quit [Ping timeout: 240 seconds]
javi404 has quit [Ping timeout: 248 seconds]
<theStack>
sipa: i would have expected that the node initiating the handshake is also the one sending the next part of the protocol first (likely, a version message?), and one could see 64 byte messages in both directions
<sipa>
@theStack That'd be gratuitously adding a (half) roundtrip. The responder can do the next step instead (indeed, a version message) first, avoiding the need for waiting for the message to be received.
<sipa>
In any case, there is definitely still identifying information in the sizes and pattern of traffic sent. But it's not nearly as detectable as looking for certain magic bytes anymore.
<theStack>
combining the handshake reponse with the version message seems like a good idea, wasn't aware that this is planned to be implemented that way (maybe it isn't yet, i will in any case keep that in the back of my head for reviewing concrete PRs)
<sipa>
@theStack Oh, this isn't the *bitcoin* version message, but the version of the transport protocol I'm talking about.
<sipa>
I don't know to what extent all these things are reflected in the spec and the implementation. The spec might not even have this versioning messge at all yet.
<theStack>
and yes, agree that with elligator square identifying is harder. i was wondering if it's worth it to add random sized data to the initial handshake to make it even harder (but probably not)
<theStack>
sipa: oh! i guess it definitely makes sense to wait for the new spec then :)
<sipa>
@theStack It's not a crazy idea, but the problem is that it can't actually be random. There is no shared secret established yet, so whatever size of stuffing is chosen, if it is to be skippable by the other party, it will also have to be known to third parties.
<sipa>
So we could decide to change it from 64 to say 256 bytes, and send part before and part after the first message by the other side.
<sipa>
But that would mean a fixed 192 bytes wasted, and leads to questions like how much waste is acceptable etc
<instagibbs>
does core currently have issues with computing bip125 inherited signaling? Lost track of this
<theStack>
i see. at least the waste argument shouldn't matter though, considering we are talking about messages that are only sent once at the beginning of a connection?
brunoerg has joined #bitcoin-core-dev
<sipa>
right... but if you pick e.g. 256 bytes, you've only introduced a variability of the first message size between 64 and 256; if you can observe many messages, and the first message is always within that range, you arguably still learn something
<sipa>
so how much is enough? 256 bytes? 4 kilobytes? 1 megabyte?
Talkless has quit [Quit: Konversation terminated!]
<sipa>
maybe it's worth having some bikeshedding over after publishing
<theStack>
yeah, good question, how to pick the range
kouloumos has quit [Quit: Connection closed for inactivity]
<bitcoin-git>
[bitcoin] brunoerg opened pull request #25253: test: add coverage for non-hex value to -minimumchainwork (master...2022-05-minimumchainwork-nonhex) https://github.com/bitcoin/bitcoin/pull/25253
bitcoinboi has quit [Quit: WeeChat 3.2]
Saloframes has joined #bitcoin-core-dev
emcy has quit [Quit: Leaving]
emcy has joined #bitcoin-core-dev
szkl has joined #bitcoin-core-dev
bomb-on has quit [Quit: aΠ»Π»ΠΈΠ»ΡΉΡΠ°!]
z9z0b3t1c has joined #bitcoin-core-dev
z9z0b3t1_ has quit [Ping timeout: 256 seconds]
sipsorcery has quit [Ping timeout: 272 seconds]
sipsorcery has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 272 seconds]
javi404 has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
ronoaldo has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
ronoaldo has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 246 seconds]