< 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
< 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 ?