< wumpus>
so it integrates somewhat more closely with the existing tests that bitcoin-tx which is an independend utility
< jnewbery>
promag: I'd say it's probably better to keep them separate if possible. Take a look at the bitcoin-tx tests in test/util. Tests for bitcoin-wallet-tool should probably go in there.
< promag>
jnewbery: do you think BitcoinTestFramework should be used/extended to support bitcoin-wallet-tool tests?
< Arvidt>
In the file there are signatures for bitcoin-0.10.4rc1 !
< Arvidt>
Is it on purpose, that the SHA256SUMs file in https://bitcoincore.org/bin/bitcoin-core-0.17.0/test.rc4/ is now named SHA256SUMS instead of SHA256SUMS.asc like it used to be named in the past? Because I have a download script and that looks for the file SHA256SUMS.asc to verfiy the download and the script does fail now because of missing signature file.
< emilengler>
Why Bitcoin Core isn't released as an AppImage ? It has a lot of advantages ?
< Jmabsd>
echeveria: (exactly this is Bitcoin Core blockchain storage, it's implementation-specific - however yea i see your point, these are not sourcecode questions)
< echeveria>
Jmabsd: these are better questions for #bitcoin.
< Jmabsd>
only block headers where the block was downloaded, is stored? so a partial sync where Bitcoin Core got the header but not the block data are dropped?
< sipa>
Jmabsd: perhaps it would be useful to search through bitcoin stackexchange about this topic, it contains a lot more information than anyone can give you on the fly here
< sipa>
there are many questions and answers about this topic on bitcoin.stackexchange.com
< Jmabsd>
What persistent indexes and databases(""tables"") does Bitcoin Core implement today?
< luke-jr>
(which can be done with: layman -a bitcoin )
< luke-jr>
wumpus: nope, the main tree is behind; he should add the bitcoin overlay
< ctrlbreak>
Should I head to #bitcoin to find out how I've screwed this up?
2018-09-18
< gmaxwell>
TD-Linux: bitcoin caps at 16 because we measured previously and found that performance stops improving there and gets worse.
< gribble>
https://github.com/bitcoin/bitcoin/issues/10271 | Use std::thread::hardware_concurrency, instead of Boost, to determine available cores by fanquake · Pull Request #10271 · bitcoin/bitcoin · GitHub
< TD-Linux>
how does bitcoin decide how many threads to use? it seems to only be using 16 on my 32 core machine
< wumpus>
did anyone urge people to upgrade in #bitcoin yet?
< wumpus>
bitcoincore.org and bitcoin.org PRs have both been merged, should be a matter of times before the sites update...
< ossifrage_>
gmaxwell, I was just building a fresh bitcoin and noticed I still had a madvise(MADV_RANDOM) when mmapping read only data in leveldb, Is this worth a PR? It seem to reduces the number of pages fetched, but I don't have a good way to show if it actually helps
< provoostenator>
I'm trying to build the man pages on a Gitian box, which doesn't have a display. Any idea how to get around "QXcbConnection: Could not connect to display" for "bitcoin-qt --help"?
< leishman>
I find the bitcoin-core-dev irc logs on botbot super useful for following development progress and learning. Are there channel logs anywhere else?
< echeveria>
zndtoshi: this is more appropriate for #bitcoin, please ask it there.
< zndtoshi>
miners. They have a veto option by signaling acceptance or not of a future softfork. But they should/will meet with everyone else at the Schelling point as well. Is there a REAL need for mining nodes to signal inside the Bitcoin Network? If not, are there any risks to remove mining node signaling?
< zndtoshi>
Pierre Rochard explained in a presentation about Bitcoin Governance that consensus is reached similary to people meeting at the Schelling point: they know the city but not the location and hour to meet. They will think what the other would do and vice versa and in NY meet in Grand Central Station at noon without communicating. So conseus in Bitcoin is the same: everyone gravitates to the right software to use or the rig
< 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 · GitHub
< jnewbery>
I'm flattered, honestly, but already too busy with bitcoin optech, residency stuff, etc
< gribble>
https://github.com/bitcoin/bitcoin/issues/14197 | [psbt] Convert non-witness UTXOs to witness if witness sig created by achow101 · Pull Request #14197 · bitcoin/bitcoin · GitHub
< 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
< kallewoof>
jimpo: reading https://github.com/bitcoin/bips/pull/725#pullrequestreview-154741923 it looks like you're suggesting the proof of funds should be a (fakeish) transaction, and the messsage signing should not be. Am I understanding that right? If so, it seems like you could just do transaction in both cases to simplify the spec. I.e. for signing message, craft two txs with the latter spending the former and former using
< gmaxwell>
I'm not aware of lightning watchtowers relaying bitcoin blocks.
< gmaxwell>
I'm not opposed it it but skeptical that its all that useful for bitcoin in general. I suggested the generic because I could imagine more uses for that. (even if just test shims)
< kallewoof>
reserve could have blinded inputs and outputs as well, or whatever else the bitcoin protocol is made to allow. As long as the spends are tangled up with the fake input (via SIGHASH_ALL or a mimblewimble kernel, or whatever), it doesn't matter."
< kallewoof>
echeveria: To quote argument for a tx-like protocol: "It also works well with proof of reserve: the proof of reserve is a bitcoin transaction spending all the funds, but with an additional input (covered by SIGHASH_ALL) that points to a fake/invalid tx. This has the additional benefit of working in a forward compatible way with any future bitcoin extension, like confidential transactions or mimblewimble: your proof of
< kallewoof>
Johnson Lau is suggesting reserving OP_MESSAGEONLY = 0xf0 as opcode for message signing, or alternatively "OP_RETURN msgXXX". It feels wasteful to take an opcode, but feedback would be nice: https://github.com/bitcoin/bips/pull/725#issuecomment-420421058
< gmaxwell>
in any case, he came up before, he's some bitconnect promoter that claims the be one of the first bitcoin developers after satoshi and a bunch of other stuff that made no sense.
< BlueMatt>
wumpus: there's a helluvalot more in rust-bitcoin than just primitives, but, ok, it *includes* primitives :p
< EucOcVrFfr2D>
achow101: By the way, i found a duplicate test for the SIGNER role (still in functional/data/rpc_psbt.json), i opened a PR to remove it https://github.com/bitcoin/bitcoin/pull/14199
< EucOcVrFfr2D>
The expected result in that test is equal to the input, the author @achow101 wanted to make sure bitcoind doesn't 'crash' on that scenario but it silently moves on. The scenario is when we're trying to sign a PSBT input but one of the requirement fails -> https://github.com/bitcoin/bips/blame/master/bip-0174.mediawiki#L342
< EucOcVrFfr2D>
https://github.com/bitcoin/bitcoin/blob/v0.17.0rc3/test/functional/data/rpc_psbt.json#L90 the PSBT contains a PartiallySignedInput where RedeemScript=[OP_2, 029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f, 02dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7, OP_2, OP_CHECKMULTISIGVERIFY] and the ScriptPubKey=[OP_HASH160, 0fb9463421696b82c833af241c78c17ddbde4934, OP_EQUAL]
< warren>
mryandao: the bigger risk is undiscovered bugs in the dependent libraries, this blew up several times in the past. Bitcoin devs found/reported/fixed many bugs in openssl and spent years to carefully write a replacement to get rid of openssl.
< warren>
Yes it would be really nice to be able to use most of bitcoin core as libraries in other projects.
< warren>
mryandao: multiple people here started years ago on the side of "This is crazy! We need to write a specification of what is Bitcoin." and a year or two of study later realize reimplmentations are too dangerous.
< dongcarl>
wumpus and I talked about perhaps writing a standalone P2P bitcoin server in Rust that can FFI with bitcoind
< mryandao>
anyone balsy enough to run parity-bitcoin?
< wumpus>
rust-bitcoin is a library that implements some bitcoin primitives in rust, it's not meant as a replacement for bitcoin core, but something like python-bitcoinlib
< dongcarl>
mryandao: rust-bitcoin isn't a rewrite yet, and BlueMatt isn't the only developer
< Jmabsd>
achow101: did Bitcoin Core have any particular point with _not_ implementing an accounts abstraction - it's just Bitcoin Core wants to provide one single wallet balance, yes?
< Jmabsd>
achow101: in other words, Bitcoin Core rolled it own thing.
< 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...