< gribble>
https://github.com/bitcoin/bitcoin/issues/16852 | gui: When BIP70 is disabled, get PaymentRequest merchant using string search by achow101 · Pull Request #16852 · bitcoin/bitcoin · GitHub
< wumpus>
#topic disable BIP70 support by default for 0.19 (BlueMatt)
< gribble>
https://github.com/bitcoin/bitcoin/issues/16852 | gui: When BIP70 is disabled, get PaymentRequest merchant using string search by achow101 · Pull Request #16852 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/16852 | gui: When BIP70 is disabled, get PaymentRequest merchant using string search by achow101 · Pull Request #16852 · bitcoin/bitcoin · GitHub
< instagibbs>
feature_block failing to sync, definitely not QT/bip70 related
< bitcoin-git>
[bitcoin] jameshilliard opened pull request #16858: Qt: advise users not to switch wallets when opening a BIP70 URI. (master...bip70-message) https://github.com/bitcoin/bitcoin/pull/16858
2019-09-11
< bitcoin-git>
[bitcoin] achow101 opened pull request #16852: gui: When BIP70 is disabled, get PaymentRequest merchant using string search (master...bip70-merchant-decode) https://github.com/bitcoin/bitcoin/pull/16852
< luke-jr>
BlueMatt: it doesn't make sense if we're disablign BIP70 too
< achow101>
it would be preferable if we could get disable bip70 in 0.19 rather than having to wait another version to let people migrate
< achow101>
if there is something that requires bip70 to decode, could you give me a code ref to it?
< achow101>
luke-jr: huh? my point was that it isn't something stored in the wallet db that requires bip70 to decode. it's a message, and afaict, it's still shown to the user, it will just look different
< luke-jr>
achow101: if you want to argue it's technically BIP70-independent since it's not on the network, okay, but the fact is that --disable-bip70 disables that code too :/
2019-09-10
< achow101>
that's not even wallet metadata, is it? It's just a display thing, nothing bip70 specific is stored in the wallet db
< luke-jr>
BlueMatt: afaik the goal is to remove BIP70 entirely - in which case, you have to turn it on BEFORE 0.20 or whatever
< BlueMatt>
(also, doesn't have to be "lost", you just have to turn on bip70 to see it)
< provoostenator>
I would say that even a false positive BIP9 activation message suggests something is going on that the user needs to look into.
< jnewbery>
achow101: almost certainly due to burying bip9 deployments
< achow101>
anyone else seeing "Warning: unknown new rules activated (versionbit 1)" in getblockchaininfo? Were we just that unlucky with asicboost miners or did burying bip9 deployments accidentally cause this?
2019-08-19
< * luke-jr>
wonders if BIP70-protocol support should be split from BIP70-parsing support, so wallets can continue to show past payments correctly once BIP70 is removed
2019-08-18
< harding>
kakobrekla: that question (and any followups you have) may be better asked in #bitcoin. The answer is that P2WPKH uses a 20-byte hash RIPEMD(SHA256()) and P2WSH uses a 32-byte hash SHA256(). For details, see https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#P2WSH
< bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #16490: rpc: Report reason for 'bip125-replaceable' value (master...1907-rpcMempoolWhyReplacable) https://github.com/bitcoin/bitcoin/pull/16490
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #16490: rpc: Report reason for 'bip125-replaceable' value (master...1907-rpcMempoolWhyReplacable) https://github.com/bitcoin/bitcoin/pull/16490
2019-08-10
< roasbeef>
sipa: nice! correct that afaik bip157 and segwit are more or less a pair
< sipa>
i've only added NODE_COMPACT_FILTER in combination with NODE_WITNESS, and not combined with NODE_BLOOM (no software using BIP157 is non-segwit, or needs BIP37 filters, i think)
< wumpus>
dongcarl: maybe this could be part of the https://github.com/bitcoin/bips/pull/766#issuecomment-517003833 sendaddrv2 message here to notify peers of addrv2 support (which was poroposed as alternative to the protocol version bump the BIP currently documents)
2019-08-06
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #16554: test: only include and use OpenSSL where it's actually needed (BIP70) (master...test_openssl_include) https://github.com/bitcoin/bitcoin/pull/16554
< bitcoin-git>
[bitcoin] fanquake opened pull request #16554: test: only include and use OpenSSL where it's actually needed (BIP70) (master...test_openssl_include) https://github.com/bitcoin/bitcoin/pull/16554
< bitcoin-git>
bitcoin/master fa8489a MarcoFalke: test: Add test for BIP30 duplicate tx
< bitcoin-git>
bitcoin/master 62117f9 MarcoFalke: Merge #16363: test: Add test for BIP30 duplicate tx
2019-08-02
< elichai2>
sipa: arghh. Is it important that every bracket will have it's own significant meaning? because using the same bracket for taproot branches and for bip32 derivations complicates stuff a bit (nothing that can't be handled with a few conditions but still) should be maybe introduce curly brackets?
< elichai2>
Is InferDescriptor *suppose* to add this fingerprint to keys(they started as regular descriptors with private/public keys, no BIP32 stuff involved)? `pkh([1fb31c4f]03462c64aa6089c6e28536c74b6ec4a8f3eaf2f5c5c36e1ae0abf39d563eeaf11e)` (it's something i'm seeing in my descriptors_tests)
< kallewoof>
So, DrahtBot added a bunch of flags to #16440 (BIP322 PR). Not sure I agree with Build system flag, though.
2019-07-31
< phantomcircuit>
hmm i was thinking we could drop the leveldb bloomfilter if the bip30 checks aren't running but actually that makes bogus transactions sent to us much more expensive to handle
< sdaftuar>
phantomcircuit: really, assumevalid has nothing to do with the optimization -- it'd be enough to check to see if a block is an ancestor of the known-bip34-activation blockhash, and if so, skip the check. i think. but this is all so complicated that i think it's best not to risk changes here...
< sdaftuar>
Anyway this would be a simple fix to your PR — just ensure that you only skip the bip30 checks if assume valid is set and the assume valid block hash builds on the known bip34 activation block hash; that would ensure that we only skip the bip30 checks on blocks we know to be safe from this issue
< sdaftuar>
it’s important to enforce bip30 on potential “alternate” chains, because if there is a utxo “overwrite” from a duplicate transaction, then the utxo set will be potentially incorrect when reorging from that chain to some other chain (eg because you’ll have removed an entry from the utxo set that should still be there, if you’d never connected the block that overwrote the transaction in
2019-07-30
< phantomcircuit>
sdaftuar, sorry im confused i dont see how removing the bip30 check would prevent a reorg to a greater pow chain
< phantomcircuit>
the BIP30 checks are literally always cache miss down to disk unless the blocks invalid
< BlueMatt>
phantomcircuit: well you at least need to fix sdaftuar's comment on the pr, but mostly I'm highly dubious of reorg conditions around the bip30 shit
< phantomcircuit>
BlueMatt, it's 10% faster to skip the bip30 checks
< jonasschnelli>
BIP324 defines short ids (single byte command) for every message.
2019-07-29
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16490: rpc: Report reason for 'bip125-replaceable' value (master...1907-rpcMempoolWhyReplacable) https://github.com/bitcoin/bitcoin/pull/16490
< phantomcircuit>
also the TODO in the BIP30 logic while not exactly immediate should be looked into
< bitcoin-git>
[bitcoin] pstratem opened pull request #16486: [consensus] skip bip30 checks when assumevalid is set for the block (master...2019-07-29-fassumevalid-bip34) https://github.com/bitcoin/bitcoin/pull/16486
< phantomcircuit>
sipa, nvm i understand how, the bip30 logic guarantees at least one utxo db access for each transaction in the block until the bip34 activation block
< phantomcircuit>
oh i see bip30
< sipa>
threre is some interaction between bip34 and the utxo logic
< harding>
phantomcircuit: BIP90 agrees that 227931 was the BIP34 activationheight.
< phantomcircuit>
sipa, i think that's the block where bip34 was activated
< kallewoof>
I am considering volunteering to help out the bitcoin/bips repository. It has 108 open PRs, dating back to 2015. Who besides Luke is maintaining that?
< stevenroose>
sipa so for the bip143 sighash calculation, do I need to provide a "witness script"?
2019-07-12
< lightlike>
sdaftuar: looks like bip37 support is on per default, but will possibly be disabled if #16152 is merged
< sdaftuar>
i'm not sure whether bip37 support is currently default on or off right now in our software, but we should do something more explicit for blocksonly connections in the future, i think.
< sdaftuar>
because bip37 allows for transaction relay to be re-enabled later in the connection's lifetime
< sdaftuar>
it's a hack -- we use a bit added to version messages when bip37 was rolled out to communicate that we don't want to enable transaction relay
2019-07-10
< elichai2>
luke-jr: that's a different thing. for taproot we need to: 1. Have an open PR. 2. Have consensus for merging. 3. have it in 0.19. 4. have BIP9 activation by miners
< instagibbs>
cool, someone had a PR for turning on bip34 for regtest, couldn't find it
2019-06-16
< dongcarl>
Looking thru BIP62 right now... I'm wondering if "2. Non-push operations in scriptSig" and "7. Inputs ignored by scripts" were ever addressed? I'm baffled by how one would address these two, although I do know that 7's OP_CHECKMULTISIG case is addressed by BIP147
< Chris_Stewart_5>
There is this section in BIP130, which is a little unclear to me "Upon receipt of a "sendheaders" message, the node will be permitted, but not required, to announce new blocks by sending the header of the new block (along with any other blocks that a node believes a peer might need in order for the block to connect)."
< bitcoin-git>
[bitcoin] laanwj merged pull request #14047: Add HKDF_HMAC256_L32 and method to negate a private key (master...2018/08/bip151_key_hkdf) https://github.com/bitcoin/bitcoin/pull/14047
2019-05-11
< gmaxwell>
sipa: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016918.html in this message Sjors recommends listing alternatives in the BIP, I strongly recommend against doing that-- it would be confusing due to distracting from what the BIP also does. BIPs should give rationale where they help add clarity on whats being done, but comparisons with untaken alternatives should generally
2019-05-07
< bitcoin-git>
[bitcoin] DrahtBot closed pull request #14049: Enable libsecp256k1 ecdh module, add ECDH function to CKey (master...2018/08/bip151_ecdh) https://github.com/bitcoin/bitcoin/pull/14049
< bitcoin-git>
[bitcoin] DrahtBot reopened pull request #14049: Enable libsecp256k1 ecdh module, add ECDH function to CKey (master...2018/08/bip151_ecdh) https://github.com/bitcoin/bitcoin/pull/14049
< sipa>
jeremyrubin: because of a stupid mistake in bip141 that makes v0 segwit with program sizes other than 20 or 32 invalid
2019-04-27
< gmaxwell>
We're removing BIP70 from bitcoin core completely, since essentially nothing uses it (except bitpay) --- we were close to removing it when they made it mandatory, then we held off, but since their implementation is hardly compatible there really isn't much reason to not remove it just for them.
< gmaxwell>
Bitpay implements BIP70 incorrectly and requires their incorrect implementation (which also creates security vulnerabilities)
< gmaxwell>
Ignoring them doesn't mean that they're magically free for asicboost use either... they're just ignored, and shouldn't be used for intentional bip9 upgrades.
2019-04-21
< harding>
filter is supposed to contain four elements: 1. the generation tx's vout0 scriptPubKey (sPK), 2. the regular tx's vin0 prevout sPK, 3. reg tx's vout0 sPK, reg tx's vout1 sPK. Does anyone know what I'm misunderstanding about BIP158? bitcoin-cli getblockfilter $( bitcoin-cli getblockhash 170 )
2019-04-19
< echeveria>
while at the tip, with bip157 enabled. restarted with actual logging.
2019-04-18
< luke-jr>
(and if it isn't, we have BIPs)
< jonasschnelli>
so we need to change BIPS.md :p
< gmaxwell>
The intentional and widely discussed design of BIP173 was to enable seemless use of future versions.
< luke-jr>
considering BIP173, it's arguably a bug to fix in backports even ;)
< sipa>
i believe this code actually predates bip173
< sipa>
this is a violation of BIP173
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #15845: wallet: Fast rescan with BIP157 block filters (master...1904-walletFastRescan) https://github.com/bitcoin/bitcoin/pull/15845
< gmaxwell>
We often decide to not support bips, less often decide to remove bips.
< wumpus>
BIP38 has some really goofy things, it was never really peer-reviewed just dropped out there,but I don't remember what anymore-please don't use it, though
< wumpus>
it does not relate to bip38 in any way; if anything, most people involved with bitcoin dev really dislike bip38 and it's per-key encryption
2019-04-10
< tynes>
its the same fingerprint used in bip173 right?
2019-04-09
< gwillen>
and yeah, the fingerprint _is_ available and works fine (it's different from the fingerprint I thought my test key had, but I got that from bip32.org and I'm sure I was just holding it wrong.)
< bitcoin-git>
bitcoin/0.18 538fef6 Pieter Wuille: Update bips.md for 0.18.0
< gmaxwell>
surplus of development resources (review, QA, design, development...), and we've also seen from the past the insecure half solutions (like BIP37) starve more secure secure approaches of resources.
< gmaxwell>
achow101: still possible some broken app was using bip32 with uncompressed keys. But I agree thats a lot less likely.
< supay>
i lost access to my bitcoin and scrubbed my system for any data i could find. found some bip32/44 paths. trying to import private keys into bitcoin core using importprivkey, but that isn't working. there aren't any errors either. any help?
< bitcoin-git>
[bitcoin] jonasschnelli closed pull request #14050: Add chacha20/poly1305 and chacha20poly1305_AEAD from openssh (master...2018/08/bip151_chachapoly1305) https://github.com/bitcoin/bitcoin/pull/14050
< harding>
echeveria: not that I'm aware of at the moment. I was thinking about 2015-17 contention between Bitcoin Core and some of the stuff Unlimited was doing. Also XT had BIP64 support and a different protocol version.
< ghost43>
to clarify, electrum used to send addresses to servers, but around the time bip173 was published, the protocol was changed to sha256(scriptPubKey), to abstract away addresses
2019-03-23
< gmaxwell>
like, if you look at bip37's other applications such as leaking lite wallet addresses, electrum does that slightly better by sending the addresses directly.
< sipa>
echeveria: as opposed to bip37, which is non optimal for everything :)
< gmaxwell>
large bip37 filters are very slow to evaluate in any case because there are many hash functions.
< luke-jr>
if not adjusting BIP158 to BIP37, maybe some other kind of address filter that could be compatible? (it won't help BIP37 then, but might reduce CPU time implementing BIP158 searches still)
< luke-jr>
could that be fixed, or would that hurt BIP158 filters somehow?
< sipa>
luke-jr: to answer your question, you can't compute the intersection between a bloom filter and a bip158 filter, as they use incompatible hash functions
< luke-jr>
sipa: but the current standard for this is BIP37 (and I would expect such bloom filters to be smaller than sending every address?)
< sipa>
and that can definitely be optimized using bip158 filters
< pierre_rochard>
"I think his desire is to allow people to immediately start using LND and the LN wallet using BIP157 filters served from his node while their Bitcoin Core node syncs."
< sipa>
it should be called BIP158, there is no p2p protocol support in there :)
< harding>
gmaxwell: yeah, and any client that supports BIP157 must, by necessity, also support grabbing and parsing full blocks anyway, so supporting grabbing all blocks after a certain height ought to be a trivial addition.
< gmaxwell>
harding: yea okay, I'd even say BIP157/158 is a pretty weak way to accomplish that particular case. ... deploying a new protocol would take a lot of time in the best case, while just fetching the blocks works now against the existing network.
< harding>
I've been trying to use "BIP157" for the filters themselves and "BIP158" for the P2P parts, but it's not always that clearcut.
< gmaxwell>
I'm not really aware of the twitter stuff (other than having been given that link) ... but my thought for many months is that I'm super excited about having the filters to make rescans usable again... and super concerned about them starting a new wave of bip37 like wallets that just blindly trust things.
< harding>
gmaxwell: AFAIU, he just wants some way for people to start using an LN wallet in the SPV trust model while their node syncs. I'm not sure he cares how it happens. I myself don't know why BIP157/158 is entangled in this, except that he might think it's necessary to accomplish that.
< sipa>
only partially related, i think there is a lot of confusion about what "bip157" means; there is (a) the spec, allowing software to implement the filters in a private protocol like wasabi does (b) support for it in bitcoin core via RPC (what the current PRs do) (c) exposing it in core and other software via P2P for trusting peers to use (d) exposing it in core via P2P for non-trusting peers (e) a
< moneyball>
My understanding is that pierre_rochard is focused on onboarding new Bitcoin users via Lightning (with his Lightning Powered Users), and he would like as many of them as possible to run full nodes, but he wants them to be able to use Bitcoin immediately so wants to support BIP157 style light clients. He's also saying if Core doesn't merge support for BIP157, he'd maintain a version of Core with it merged, and run
< harding>
gmaxwell: pierre_rochard maintains an installer that installs Bitcoin Core, LND, and a LN wallet that's capable of using BIP157/158. I think his desire is to allow people to immediately start using LND and the LN wallet using BIP157 filters served from his node while their Bitcoin Core node syncs. That is, I don't think he's talking about hybrid SPV in Bitcoin Core by hybrid SPV via LND/Neutrino/some other wallet.
< gmaxwell>
Can someone explain this tweet people were passing around? https://twitter.com/pierre_rochard/status/1104785795523719169 I don't understand how fullblock spv mode and the BIP157 related PRs are at all compariable/substutiable for each other.
< gribble>
https://github.com/bitcoin/bitcoin/issues/13134 | net: Add option `-enablebip61` to configure sending of BIP61 notifications by laanwj · Pull Request #13134 · bitcoin/bitcoin · GitHub
2019-03-13
< dta_>
bip16?
2019-03-12
< bitcoin-git>
[bitcoin] fanquake opened pull request #15584: build: disable BIP70 support by default (master...disable-bip70-by-default) https://github.com/bitcoin/bitcoin/pull/15584
2019-03-11
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #15566: cli: replace testnet with chain and return network name as per BIP70. (master...cli-testnet-to-network) https://github.com/bitcoin/bitcoin/pull/15566
< bitcoin-git>
bitcoin/master 890396c fanquake: cli: replace testnet with chain and return network name as per BIP70.
2019-03-09
< bitcoin-git>
[bitcoin] fanquake opened pull request #15566: cli: replace testnet with chain and return network name as per BIP70. (master...cli-testnet-to-network) https://github.com/bitcoin/bitcoin/pull/15566
2019-03-08
< pinheadmz>
thanks guys, going to get the team on BIP130
< sipa>
bip130 is a step being headers-first sync
< sipa>
and with BIP130, new blocks are also announced using headers instead of invs
< pinheadmz>
looking into it now... is the deprecation of getblocks documented? I was about to start work on BIP159 (NETWORK_LIMITED) but maybe I should checkout the existing networkprotocol behavior first. bcoin does send `sendcmpct` and then `getblocks` which will retrieve compact blocks from the peer.
< gmaxwell>
it would be like sticking a warning on BIP69 txn. They're a minority of transactions so in that sense they hurt the user's privacy.
< gmaxwell>
bip69 also just didn't add anything in and of itself, it's not like there was a "this is much better but its inconsistent so don't do it"
< shesek>
re "(esp if everyone isn't suicide packed into never improving)" - for a wallet that wants to maximize its anonymity set, it makes sense to use characteristics that are as common as possible, even if its less ideal for other reasons. for example, payjoin are intentionally trying to avoid uih-2 to enjoy a bigger anonymity set. and some of the arguments against bip69 lexicographical ordering were on a similar basis, that wallets that do
2019-03-07
< wumpus>
I... don't understand why such a high-level discussion of the desirability of those things comes now, while BIP150/151 have existed for ages
< jonasschnelli>
Auth. is BIP150 which is still in discussion
< jonasschnelli>
BIP151 (or the new #) is opportunistic encryption
< jonasschnelli>
Also, there is a BIP150 weakness if used with plain (old) BIP151
< sipa>
jonasschnelli: it looks like you plan to overwrite BIP151... given that it already has a bip number, and you're substantially changing the design, maybe it should be a separate one
< sipa>
(and abandon bip151)
< jonasschnelli>
Though we must discourage to use BIP151
< wumpus>
gmaxwell: I tend to agree at this point, years ago it was differnt but makes sense to prioritize BIP150/151 now
2019-03-06
< andytoshi>
i'd like to start a wiki page or github issue or something to collect a wishlist for a bip174/psbt extension BIP draft. where is the best place to do that?
2019-03-05
< gmaxwell>
mmgen: hardend bip32 is a hash derrived private key, you are spreading disinformation claiming that it has any different security properties.
< mmgen>
gwillen: my concern with bip32 is that is uses ecc, which could be a problem after the advent of quantum computing
<@gwillen>
FWIW I think your tool looks cool, although I am skeptical that your alternative to BIP32 is an improvement but I'd be interested to hear about the motivation behind it (but not in this channel, perhaps #bitcoin-dev would accept such a conversation)
< jonasschnelli>
Which shows a tendency that something like BIP151 may speed up processing performance on ARM... especially small packets
< luke-jr>
rafalcpp: this is not a BIPable topic
2019-03-04
< jonasschnelli>
The current BIP151 way is ECDH_SECRET->HKDF->k1 for AAD encryption, ECDH->HKDF->k2 for the payload encryption
2019-03-01
< provoostenator>
Although it would be safer when combined with native-descriptor wallets, because the behavior of getnewaddress doesn't jive well with BIP44/49/84 that wallets use.
2019-02-26
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #13972: Remove 16 bits from versionbits signalling system (BIP320) (master...reservedbits2) https://github.com/bitcoin/bitcoin/pull/13972
< bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #13972: Remove 16 bits from versionbits signalling system (BIP320) (master...reservedbits2) https://github.com/bitcoin/bitcoin/pull/13972
< gribble>
https://github.com/bitcoin/bitcoin/issues/15482 | Implement BIPXXXs new softfork rules (The Great Consensus Cleanup) by TheBlueMatt · Pull Request #15482 · bitcoin/bitcoin · GitHub
2019-02-25
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #15482: Implement BIPXXX's new softfork rules (The Great Consensus Cleanup) (master...2019-02-great-consensus-cleanup) https://github.com/bitcoin/bitcoin/pull/15482
< sipa>
bip32 derived keys are always compressed
< sipa>
but xpub serializations always uses compressed... so integrating bip32 with uncompressed keys seems hard in any case
< sipa>
and bip32 only supports compressed keys, iirc
< dongcarl>
For BIP32, is the identifier the Hash160 of the compressed or uncompressed serialization of the ECDSA public key?
< MarcoFalke>
BIP320 could make sense to make it explicit, but that can be done for 0.19 or not at all
< wumpus>
I also wonder how much it matters, it's not that BIP9 is reliable anymore for those bits
< MarcoFalke>
Is there any chance that there will be a softfork deployed not via BIP9?
< provoostenator>
The nUpgraded warning says "It's possible unknown rules are in effect", but that's only possible if a lower threshold or some other upgrade mechanism than BIP9 is introduced.
< provoostenator>
If we change that to tracking each bit individually, then there wouuld have been no alerts expect for SegWit and BIP91.
2019-02-19
< provoostenator>
In addition I think the same or a similar dialog can be used to recover wallets. Could be loading a wallet dump file, entering some descriptors or even bip39 phrases.
2019-02-18
< palfun>
luke-jr: right, so importing "used" bip32 wallets will be slow to detect all previous usage. does that still get done automatically, do I kick that off, or do it manually?
< palfun>
so for the bip32 case, you'd just feed it your first 20 addresses, see what turns up, and then proceed as appropriate
< sipa>
bip37 is server side filtering
< luke-jr>
you mean server-side for BIP37, right?
< sipa>
bip37 allows client-side filtering (it has severe privacy concerns, and is not advised), or client-side filtering (bip157, which is still new)
< palfun>
wait, but, then how do bip32 wallet clients work? they need to scan large amounts of addresses for outputs/transaction history right?
< jarthur>
bitcoinEnthusias: the BIPs are designed to be readable and reviewable, and Python tends to work well for that.
< jarthur>
bitcoinEnthusias: on the protocol side, sipa has been organizing a BIP for Schnorr signatures. It hasn't officially been proposed yet, and typically an implementation would follow a proposal. https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki if you want to see the current state. bitcoin-dev mailing list a fine place to discuss the proposal
< luke-jr>
wumpus: BIP150/151 solve authentication when they're finally done, but I don't see any better solution for dynamic IPs and NAT traversal (when UPnP/NAT-PMP are unavailable).. at the end of the day, I'm not sure it makes sense to reinvent what already exists
< provoostenator>
Agreed, the combination of PMP/UPNP and ~BIP150 seems a more precise tool for this job.
< gmaxwell>
technically BIP150 (or whatever replaces it... sipa and I really need to finish that)
< wumpus>
also I've always believed the way forward would be to improve the bitcoin protocol itself; BIP150/151, Dandelion, as well as lightning onion routing
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #15411: travis: Combine --disable-bip70 into existing job (master...Mf1902-travisBIP70) https://github.com/bitcoin/bitcoin/pull/15411
< bitcoin-git>
[bitcoin] jonasschnelli merged pull request #15063: GUI: If BIP70 is disabled, attempt to fall back to BIP21 parsing (master...bip70_fallback_to_bip21) https://github.com/bitcoin/bitcoin/pull/15063
< bitcoin-git>
bitcoin/master 84f5315 Luke Dashjr: Travis: Add test without BIP70 (but still full wallet + tests)
< bitcoin-git>
bitcoin/master 113f000 Luke Dashjr: GUI: If BIP70 is disabled, give a proper error when trying to open a payme...
< bitcoin-git>
bitcoin/master 9975282 Luke Dashjr: GUI: If BIP70 is disabled, attempt to fall back to BIP21 parsing
2019-02-13
< sipa>
it's testing that pushing a script hash using the OP_PUSHDATA opcodes doesn't cause it to be detected as P2SH (because BIP16 gives the exact encoding)
< sipa>
but something like bip32 is already somewhat harder to do for ed25519
2019-02-07
< jl2012>
in BIP143, out-of-bound SINGLE is treated like NONE
< stevenroose>
luke-jr: people don't like BIP70, though :)
2019-01-28
< luke-jr>
stevenroose: BIP70 had chain ids as strings
< stevenroose>
I could do network magic bytes, psbt prefix, BIP44 coin type id, base58check address prefix byte (f.e. fixed at p2pkh), ... Address-specific ones are probably very bad.
< stevenroose>
I think magic bytes are quite solid. More available in implementations than BIP44 coin type ids, f.e..
2019-01-25
< gmaxwell>
talk of multiwallet gui makes me wonder if anyone is working on using BIP157 filters for rescan? Personally I found multiwallet not super useful, due to the need to rescan wallets that were left unloaded, and it taking 8 hours to do so...
2019-01-24
< sipa>
so you can use hardened bip32 keys as descriptor; they need access to the private key to derive, but not to otherwise use
< gmaxwell>
They are but they need to be part of any BIP70 alternative that doesn't immediately broadcast txn.
< gmaxwell>
At the time BIP70 was written, the only 'used' metric bitcoin core really had was "spent by the mempool"
< gmaxwell>
BIP70 could have been defined that way, varrious people advocated for it.
2019-01-09
< gmaxwell>
roasbeef: their bip70 violates the spec and can't be used with bitcoin core regardless.
< roasbeef>
luke-jr: orly? iirc they enforce it and there's no other way to pay them other than via bip70
< luke-jr>
phantomcircuit: BitPay isn't even BIP70-compatible
< phantomcircuit>
gmaxwell, as far as i know literally only bitpay uses bip70
< gmaxwell>
yea, I think bip70 as an external program would be nice, except no one cares about it...
< echeveria>
if this was my software I'd be putting a bounty in the bip70 payment window to see if anybody notices it. you found the secret bit! send a letter to this address and we'll mail you a prize!
< echeveria>
gmaxwell: sipa: bip70 could kinda be a different binary at this point, but I don't think it's level of use justifies any sort of investment in development.
< gmaxwell>
Also BIP70s implementation inherently had to be run from a wallet.
< provoostenator>
BIP70 is depreacted so depending on when disaster happens, we could then just ship a new binary with OpenSSL removed.
< gmaxwell>
via bip 70 though it could actually introduce vulnerabilities, though thats really a question about getting rid of bip70, not openssl.
< gmaxwell>
[ignoring BIP70] Now we're just stuck issuing new binaries the next time there is some zomg panic about openssl because we statically link to it.
2019-01-03
< jamesob>
oops I'm sorry -- that jimpo PR isn't critical path for BIP157; I meant #14085
< jamesob>
can I nominate jimpo's BIP157/8-related PRs that've been hanging out for a while? maybe starting with #14111?
2018-12-30
< bitcoin-git>
[bitcoin] luke-jr opened pull request #15064: [PoC] GUI: Migrate BIP70 merchant info to mapValue["to"] (master...bip70_merchant_to_to) https://github.com/bitcoin/bitcoin/pull/15064
< bitcoin-git>
[bitcoin] luke-jr opened pull request #15063: GUI: If BIP70 is disabled, attempt to fall back to BIP21 parsing (master...bip70_fallback_to_bip21) https://github.com/bitcoin/bitcoin/pull/15063
< gmaxwell>
Perhaps because they realized if they kept it up BIP37 was just going to end up removed and then they'd lose their toy. Who knows.
< gmaxwell>
roasbeef: quite a few nodes just disable BIP37 completely (which seemed to stop the BIP37 based attacks)
< roasbeef>
it's a win for full nodes at least, serving the filters is much less intensive (and also stateless) compared to serving bip37, you also can't trigger worst case matching behavior over the entire chain
< gmaxwell>
One should also consider the effect of incentiving varrious kinds of trouble making. (like generally we've found that when we added vulnerablities like BIP37 attackers emerged that didn't exist previously, and then made more trouble even for people that didn't care about using BIP37)
< gmaxwell>
I'm very glad, e.g. that nothing about BIP37 ended up softforked in... that protocol turned out to be a lemon in a number of ways, but it took a couple years of use to realize that.
< sipa>
it's pretty trivial to do, but mucb easier to get agreement on once bip157 itself is deployed and used
2018-12-20
< jonasschnelli>
I think the initial design came from the two step BIP151 handshare where v1 protocol was required for the initial messages
< jonasschnelli>
So there could be two serialization instance (legacy p2p and BIP151 p2p) where each node would hold a shared pointer to that instance?
< gmaxwell>
phantomcircuit: indeed. But for that case, you'd still probably be just as well off with bip157 filters on disk, and sequential scanning those.
< sipa>
provoostenator: yes, i think BIP157 may be useful for a new class of clients that may become popular
< gmaxwell>
(it's worse because it takes a client more time to scan the chain than with BIP37, as it has to get quite a bit more data)
< gmaxwell>
and that doesn't really have anything to do with bip158 vs bip37.
< gmaxwell>
(in fact BIP158 is somewhat worse, but slightly less of a privacy disaster)
< jamesob>
good point - but I guess if existing light wallets switched to bip157 it'd at least ease load on existing full nodes
< provoostenator>
gmawell is that _because_ of bip158 or just because there aren't that many developers working on light (non web, non electrum) wallets? That could change over time.
< gmaxwell>
jamesob: history has shown otherwise, bip158 doesn't make lite wallets fundimentally more usable than they are now. They're still massively worse than server driven wallets like electrum or web wallets.
< sipa>
luke-jr: BIP158 helps our local wallet too
< jamesob>
are any of the BIP157/158 PRs on the high prio list? if not, they should be
< gmaxwell>
jonasschnelli: e.g. saved the bip157 filters locally, and scan against them.
< provoostenator>
jonasschnelli: BIP44 recovery can be handled once we have descriptor support for importmulti and slightly more sane behavior (or a replacement for) the keypool.
< jonasschnelli>
Sadly people expect fast BIP44 recovery (incl. history). This seems to be the most prominent real-world usecase for an address index
2018-12-07
< sipa>
jamesob: i think bip157/158 are great
< jamesob>
it sounds like BIP-0157/0158 would go a long way towards the scan approach which is also something I'd like to talk about at some point... is anyone aware of any outstanding concerns with these BIPs and any reason we shouldn't be pushing forward on jimpo's related PRs?
2018-12-06
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #14564: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI (master...bip70-disable-check) https://github.com/bitcoin/bitcoin/pull/14564
< bitcoin-git>
bitcoin/master 23a1fa0 MarcoFalke: Merge #14564: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI...
< bitcoin-git>
bitcoin/master 58c5cc9 James Hilliard: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI
2018-11-30
< provoostenator>
By default we ask for a standard BIP44/49/84 path
< luke-jr>
[17:57:13] <gmaxwell> We could, in the future, introduce a replacement to that rpc that does it implicitly, for example. <-- breaking all compatibility with the BIPs and existing software? :/
2018-11-19
< gmaxwell>
It just sounded vaguely related to me (new distro + bip70 + crash on start)
< BlueMatt>
anyway, can I just remove bip70 now? :p