< 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...
< bitcoin-git>
bitcoin/master fa309dc MarcoFalke: validation: Log FormatStateMessage on ConnectBlock error in ConnectTip