< Jmabsd>
achow101: so Bitcoin Core cut away the "coin" and the "account" derivation, and set purpose to 0 - that's pretty much it yes?
< Jmabsd>
does Bitcoin Core do BIP 44 "m / purpose' / coin_type' / account' / change / address_index" form at all?
< Jmabsd>
What is the structure of Bitcoin Core's HD wallet now (derivation paths); it's not going with BIP 44/49 today is it?
< kallewoof>
achow101: is it, really? (easier to implement) In bitcoin core, I would add a BaseSignatureChecker that took a sighash and that's all. Just call VerifyScript with the inputs from the SignatureProof container.
< kallewoof>
Several people on https://github.com/bitcoin/bips/pull/725 (Generic Signed Message Format) are suggesting I use a fake tx that the prover simply signs. I'm not sure what the benefits of doing this are, though..
< gribble>
https://github.com/bitcoin/bitcoin/issues/14196 | [0.17][psbt] always drop the unnecessary utxo and convert non-witness utxo to witness when necessary by achow101 · Pull Request #14196 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< dongcarl>
Looking into libconsensus as well... I'm wondering if the API detailed in https://github.com/bitcoin/bitcoin/issues/6714 still holds... Seems like jtimon and NicolasDorier did a bunch of work that's been closed due to inactivity?
< echeveria>
hey at least bitcoin doesn't make HTTP requests using raw sockets now.
< CubicEarth>
In either case though, if blocks are to be retained until the pruning command is given by another service, it seems useful to have bitcoin have an option to not download more than some MBs or GBs worth of blocks
2018-09-08
< CubicEarth>
but if lightning isn't started at same time, bitcoin will go ahead and fill all space it can find
< CubicEarth>
it would be cool to have bitcoin not prune any blocks unless manually instructed, and yet also respect a storage limitation. So until manual pruning happened, it wouldn't download new blocks beyond some point.
< gmaxwell>
this got answered hors ago in #bitcoin.
< Jmabsd>
<crosspost from #bitcoin, please respond at #bitcoin, sorry for spam>Can I add witness data to a transaction input that is not necessarily segwit and where the witness data i'd add is unrelated to the output the input spends?</spam>
< * wumpus>
still remembers in the old bitcoin source, satoshi had remapped 'printf' with a macro, now that was confusing, but we should make a habit of switching around log function names that just adds to cognitive load
< BlueMatt>
ah, right, the exploit-timeward-to-change-blocktime-and-fork-to-lock-it-in thing....I feel like thats something that needs more broad bitcoin-dev or whatever discussion, its not something to be discussed a technical planning meeting
< moneyball>
* hardware wallet support in Bitcoin Core
< moneyball>
* partially signed bitcoin transactions
< gmaxwell>
Maybe people could think about rhavar's bustapay... I think it might be reasonable to support it in the bitcoin core wallet.
< as1nc>
hello folks, beautiful day here in south of france, bitcoin is doing great, what else can we ask ? :) oh yeah, anyone has any tips on how I could guess what type of a addresses is used (p2sh, p2pkh..) given an xpub, ypub or zpub key ? is that even possible ?
< achow101>
both gmail and protonmail show me "from: X via bitcoin-dev"
2018-09-03
< kanzure>
sipa: apologies. mailing list is in moderation mode since someone figured out how to spoof emails from bitcoin developers. emails were delayed due to my travel.
< gmaxwell>
Aside, AFAICT walletprocesspsbt doesn't even show the fees. nor does decodepsbt... so using bitcoin core rpc as your HSM doesn't even provide any security improvement from having the inputs present? or am I missing it?
< jonasschnelli>
kanzure: is there an issue with the bitcoin-dev mailing? I sent an email 7h, but got nothing back from the list
< sipa>
gmaxwell: well, right now, the implementation in bitcoin core isn't sufficient for non-wallet operation
< gmaxwell>
I understand how the bitcoin protocol works. I'm surprised that there isn't any way to bypass checking the inputs.
< wumpus>
as1nc: would be better to ask in #bitcoin, this channel is for bitcoin core development
< wumpus>
bitcoin core ofc
< as1nc>
wumpus, did you send the coin within bitcoin core, or another wallet ?
< as1nc>
yeah i understand, but i'm bulding a service for user to accpet bitcoin via web interface providing only their extended public keys, and I really want to provide a testnet api
< gmaxwell>
(and before anyone things "but bitcoin traffic doesn't really need to be tamper protected" -- it's important to authenticate encrypted data or you can use targeted tampering to extract small amounts of data from encrypted links by tampering and observing what happens)
< gmaxwell>
(in fact, bitcoin core computes the hash incrementaly)
2018-09-01
< gmaxwell>
there should be no particular reason that someone couldn't run a fully functional bitcoin node using a few tens of MB of ram... though obviously not one with the lowest possible latency.
< dongcarl>
Have there been any thoughts put into an identicon/visual hash representation of Bitcoin addresses for improved user experience? Would that be useful in any way?
2018-08-30
< echeveria>
"The receiver is responsible in making sure the "partial transaction" returned by the sender was changed correctly (it should assume the connection has been MITM'd and act accordingly), resign its original inputs and propagates this transaction over the bitcoin network. The client must be aware that the server can reorder inputs and outputs."
< sipa>
that would defeat the purpose of not being recognizable as bitcoin traffic
< jonasschnelli>
Also, the v2 handshake doesn't reveal "bitcoin traffic" (not very DPI resistant though)
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #14101: qa: Use named args in validation acceptance tests (master...Mf1808-qaNamedArgsAcceptance) https://github.com/bitcoin/bitcoin/pull/14101
< bitcoin-git>
[bitcoin] laanwj closed pull request #14097: validation: Log FormatStateMessage on ConnectBlock error in ConnectTip (master...Mf1808-validationLogError) https://github.com/bitcoin/bitcoin/pull/14097
< bitcoin-git>
bitcoin/master 4e9a6f8 Wladimir J. van der Laan: Merge #14097: validation: Log FormatStateMessage on ConnectBlock error in ConnectTip...
< bitcoin-git>
bitcoin/master fa309dc MarcoFalke: validation: Log FormatStateMessage on ConnectBlock error in ConnectTip
< gmaxwell>
But say, for example, we decide we want to have a HEADERS2 message coded as value 27 in bitcoin core. We're going to negoiate its activation with something like SENDHEADERS. Say another implementation BitcoinConnectUnlimitedClassic (BCUX) wants to use 27 for XHEADERS. An implementation could support talking to both kinds of peers just by assigning the meaning of 27 based on the negoation.
< ossifrage>
looking at: pmap -x $(pidof bitcoin-qt) | grep .ldb | awk '{if($3 == 0){print}}' shows that many of the ldb files aren't using any RSS memory (after being up for almost a month)
2018-08-26
< gmaxwell>
in bitcoin we're seeing an increase of hundreds of meg.
< wumpus>
luke-jr: the only reason that the change to num files was acceptable is because leveldb, at least the version in our tree, doesn't actually keep more files open (on platforms with mmap) see also https://github.com/bitcoin/bitcoin/pull/12495#issuecomment-377228329
< Jmabsd>
> sipa, right and when getting a disassembly printout in Bitcoin Core and related tools, those 20B:s are printed in normal order
< Jmabsd>
What about pubkey hashes (20B), pubkeys (32B) and signatures (64B) - are those printed in normal or reverse byte order? so, I have a P2SH pubkey script, say. in there is a 20B hash of my redeemscript, right. when I use Bitcoin Core's script disassembly function, will it print that hash in byte or normal order? i mean there is an outer extent to what Core prints in reverse order - for instance, binary transaction dumps (in hex) are in
< Jmabsd>
wait, so Bitcoin has the tendency to print (256 & 160bit) hashes in *reverse* order, right - block hashes, transaction hashes and merkle root hashes.
< as1nc>
jonasschnelli, yes but i really want to incite people to txindex their chain so they can benefit the full spectrum of bitcoin capabilities. lightning for exemple require a txindexed chain right ?
< MaxHastings_>
jonasschnelli: Ah I see I did not know bloom filters were ineffective for keeping user privacy. Are there any other missing vulnerabilities on that page other than privacy concerns? I was told on Bitcoin slack that the SPV client could be tricked to change its consensus rules by malicious nodes.
< jonasschnelli>
But its OT in this channel... so use #bitcoin
< gmaxwell>
AFAIK, it just works. It's kinda limited though because none of them resist traffic analysis and it's SUPER easy to identify bitcoin traffic with traffic analysis. :)
< gmaxwell>
wumpus: I think jonasschnelli suggests that we have support for these obfscuated transports without putting tor in the middle. I think we already do (in fact, I used one of the ones made for tor to bridge bitcoin nodes last year when we were worried about china blocking bitcoin... before later changing to an icecast stream so that it wouldn't be identifyable by traffic analysis)
< jonasschnelli>
The idea is to make Bitcoin work in DPI env in case it would get blocked,.. like China or Iran
< wumpus>
integrating tor's code into bitcoin core is not a good idea
< sipa>
how is it bitcoin specific, or what do you specifically propose?
< wumpus>
looks like a layer violation to worry about this? or do you want to make tor tunnel over bitcoin instead of the other way around?
< _flow_>
What can I do to get https://github.com/bitcoin/bitcoin/pull/13621 merged? It improves the, currently terriable, configuration mechanics of bitcoind a bit (while still not perfect) and re-enables a recently disabled test.
< gnappuraz>
thx for the answer. But let's assume that I have to add a new file that if meant to be use by both bitcoind and bitcoin-qt, the rationale behind putting it in COMMON vs UTIL should be: if used by bitcoin-cli then UTIL, otherwise COMMON (since bitcoin-cli links UTIL but not COMMON)?
< jonasschnelli>
gnappuraz: these are semi-independent modules. Those modules get linked for the different binaries we have (bitcoin-tx, bitcoin-cli, bitcoind, bitcoin-qt).
< Jmabsd>
derp derp, ok Bitcoin Core gonna kick in more reverse order hex conventions in the ecosystem over time, he he. however users won't care really about those.
< achow101>
(in a modification of Bitcoin Core)
< Jmabsd>
gmaxwell: exactly, Bitcoin Core's HDwallet seeds are 160bit and presented in reverse order, yes
< Jmabsd>
some other hash, even if it relates to the bitcoin protocol, then normal order is fine
< Jmabsd>
achow101: exactly. so all over the whole Bitcoin ecosystem, those three values (block HASH, transaction HASH and merkle root HASH aka ID whatever), when you're dealing with hex representation, it must ALWAYS be in reverse order bc otherwise you'll screw up
< achow101>
Jmabsd: fun fact, bitcoin core does exactly that
< Jmabsd>
so we can only understand that transaction id:s and merkle root id:s (and in Bitcoin Core's case also hd wallet seeds) got this reverse byte order,
< achow101>
Jmabsd: Bitcoin Core checks that if the block hash is bigger than the target, it should fail, hence the return false that follows
< Jmabsd>
achow101: the "nBits" value, which is copied from the block header and is applied in PoW here https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L80 : "arith_uint256 bnTarget;bnTarget.SetCompact(nBits, &fNegative, &fOverflow);" , it's in the Bitcoin-internal 32bit floating point format right??
< Jmabsd>
wait, hashes are such are binary/byte concepts so the whole idea of relating to them as comparable numbers, is a concept that Bitcoin adds on top of them, right? the inventor of SHA256 never related to hashing as SHA256(byte string) => 256bit integer which may be little or big endian, right?
< Jmabsd>
dcousens: aha. Bitcoin Core would print the merkle root in reverse order. anyhow right.
< Jmabsd>
(which is some Bitcoin transaction for some purpose)
< Jmabsd>
for instance, for symmetry with Bitcoin, if you make a Dcousens Bitcoin Transaction format, then obviously its hash should be printed in reverse order.
< Jmabsd>
dcousens: yeap i see. i'm trying to make just a bit of sense here, so that, if you make a Dcousens Protocol to do some Bitcoin-related stuff, and you have some structure in your protocol that you hash and then give to people, in what order should it be.
< Jmabsd>
that makes sense yes. what code in Bitcoin Core compares two uint256:es, which would be used for sorting?