< Pritty_Kitty>
Will i use the "hash" field to create my witness hash tree and put a commit in my coinbase value? Do i put this commit value AFTER the BIP34 blockheight value?
< luke-jr>
reckon it'd work to add the few BIP17 stuffs watch-only scripts?
< * luke-jr>
ponders how to fix his wallet; IsMine isn't returning true for BIP17 stuff way back when :x
2018-01-12
< gmaxwell>
So you could just as well say that the pr12119 is "use BIP142" ... I wouldn't bother clarifying it, but the fact that there is not a 1:1 relationship between scripts and addresses is pretty important for cases like sipa points out.
2018-01-11
< gmaxwell>
There are also other address encodings for that same script, e.g. BIP142 (though hopefully no one uses them)
< jonasschnelli>
10387 is independent from the BIP159 signalling.... connecting would be nice though, but includes some risks.. so no hurry with that
< SopaXorzTaker>
Why does "satoshi" appear in the BIP39 wordlist?
< sdaftuar>
gmaxwell: re #11739 -- thoughts on next steps there? i was thinking i need to document the change somehow, perhaps an update to the relevant bips and an email to the -dev list?
< BlueMatt>
you can change the bip9 activation parameters option thinggy so they match
2018-01-05
< jimpo>
Yeah, I'm pretty close with the drafts of the revised BIPs (I'm thinking 2 instead of 1, though it might end up just being one huge one). Need to run the changes by roasbeef.
< BlueMatt>
echeveria: yea, well bip37 should be killed off entirely at this point anyway
< echeveria>
BlueMatt: I'd have to check, not when I last looked. there's also like, 2 BIP37 wallets in use today.
< echeveria>
luke-jr: blocksonly is pretty much a DOS on bad bip37 peers expecting unconfirmed transactions.
< BlueMatt>
also, my point stands - bip37 nodes *also* receive filtered blocks, it may be that they're ok with just that
< phantomcircuit>
it sets the flag in the version message which was part of the bip37 changes originally
2018-01-04
< sdaftuar>
if so i feel like next step would be for me to email the dev list and figure out a way to document this (maybe update one of the existing bips?)
< provoostenator>
Or maybe the "simple IPC mechanism" wouldn't need the RPC, but it's not clear to me how this would work (other than the fallback to BIP21, but that's not enough).
< wumpus>
SPV wallets of any kind only have to sync from their birthday, so I don't see why '45 minutes to sync over bip37' unless it's an old wallet that hasn't been synced for a long time
< wumpus>
(which bip37-based, or even full block SPV approaches would suffer from)
< wumpus>
yes, exposing bip37 to random nodes was probably not the best idea
< echeveria>
I was busy making sure bip37 was disabled on my nodes, that's all.
< echeveria>
it takes like, 45 minutes to sync over bip37 now and it shreds the node you're connected to.
< echeveria>
damn, was chewing as missed my 'inb4 bip37'.
< luke-jr>
need BIPs 150 & 151 to do that reasonably safe
2017-12-27
< cluelessperson>
Pretty much everything uses BIP32/44 | xpriv,xpub right?
< sipa>
bip32 yes
< sipa>
but electrum does not follow bip44 afaik
< cluelessperson>
gmaxwell: Another idea comes to mind. Suppose I should focus on writing up a list of reasons *why* I felt I'd want to change the wallet.dat structure. Part of it was to make it portable, modifiable, and allow users to just insert new keys at whim, from Electrum, BIP39, xpriv, xpub, WIF, mini, etc.
2017-12-20
< maaku>
I've moved some discussion regarding implementation of BIPs 98, 116, and 117 to #bitcoin-mast
< bitcoin-git>
[bitcoin] jnewbery opened pull request #11817: [tests] Change bip68-112-113-p2p to use BitcoinTestFramework (master...refactor_bip68-112-113-p2p) https://github.com/bitcoin/bitcoin/pull/11817
2017-11-23
< jonasschnelli>
The "just works" approach is very important and a reason why I try to kick BIP150/151 forward even with the fact that it's already sort of possible with stunnel, VPN, TOR
< jonasschnelli>
BIP150/151 would work towards trustworthy direct connections
< jonasschnelli>
a) you use BIP150 (or other enc/auth) via p2p and use SPV BF on your phone/remove client
< Provoostenator>
(assuming BIP150/151 for the sake of argument)
< jonasschnelli>
sipa: is that scheme: (k1+H(k2,R1))*G = k1*G+H(k2,R1)*G = R1+H(k2,R1)*G compatible with BIP32?
< gmaxwell>
jonasschnelli: the other thing is this KDF scheme. Basically, I want to address the problem that you want to enter a password protected seed on a hardware wallet and not expose the password or seed to an untrusted host... but the hardware wallet does not have enough CPU power to do a meaningful KDF (the 2000 rounds in BIP39 is basically pointless)
< jcorgan>
physical damage aside, i'm still not sure if any proper bip32 hd-wallet seed/hierarchy designs have emerged
2017-11-16
< jonasschnelli>
I'm not sure if a plain text seed dump (or BIP39) is something you want in a bank tresor
< jonasschnelli>
Somethine we (HWW company) do discuss regularly is how we can make the backup situation better.. a lot of things are involved. Bip39, sdcard, shamir's secret, notary services, etc.
< jonasschnelli>
PBKDF2 with 2048 rounds seems not ideal (BIP39)
< jonasschnelli>
gmaxwell: I'm happy to hear your bip39 successor HWW KDF idea...
< gmaxwell>
achow101: unless I'm confused (always likely) it's just a minor fixup of BIP39.
< gmaxwell>
achow101: ugg electrum itself. can't encode arbritary data, so it can't work with existing wallets. at least it's better than bip39.
< gmaxwell>
achow101: not bip39 as it's a brainwallet scheme that can't encode arbritary data, but yes.
< achow101>
gmaxwell: recovery code as in something like bip39?
< sipa>
jnewbery: i was starting to respond to you, but to the last point "We already have control to make a BIP9 deployment active at a certain height in regtest using -vbparams. What advantages do you see for making a deployment buried instead of just activated at a height?" -> -vbparams doesn't permit having segwit active before block 432
2017-10-08
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11463: BIP148 user activated activation of segwit (master...bip-segwit-flagday) https://github.com/bitcoin/bitcoin/pull/11463
< bitcoin-git>
[bitcoin] jackpot1136 opened pull request #11463: BIP148 user activated activation of segwit (master...bip-segwit-flagday) https://github.com/bitcoin/bitcoin/pull/11463
< gmaxwell>
luke-jr: yes for HB BIP152 we don't to validation except hashing!
< gmaxwell>
I think the interaction isn't too bad, for this purpose a BIP152 CB HB block is relaying you the header of its parent.
< sdaftuar>
luke-jr: even with bip152 the headers need to be valid
< gmaxwell>
luke-jr: the only place that happens in the protocol is HB BIP152 messages.
< jonasschnelli>
tloriato: AFAIK BIP45 is the only "standard" to create multisig addresses with a set of given pubkeys.
< tloriato>
Good afternoon. I was looking into BIP45, that tries to standardize the Structure for Deterministic P2SH Multisignature Wallets, but I've read the emails discussing it and seems to have a little or disagreement between the need for this particular BIP. I'm wondering if there is another standard way to generate a Deterministic Multisig Wallet? I was inclined to generate a standard Mnemonic (BIP39) and split it using Shamir
2017-10-04
< jonasschnelli>
BlueMatt: yeah. Happy to pull-in a cleanup into bip159 PR
2017-10-03
< cfields>
sipa: what do you think about a NODE_FULL (or so) flag which indicates that the node can validate the entire chain? That way (say in a year or two from now), we can require NODE_FULL, prefer NODE_NETWORK, and tolerate NODE_NETWORK_LIMITED ? I really don't like the outbound selection policy wonkyness that bip159 gives us.
< jtimon>
re https://github.com/bitcoin/bitcoin/pull/11398 I wonder if we should always leave at least the last bip9/bip8 deployment there to make sure we're using the rpc part of bip9
< bitcoin-git>
[bitcoin] jtimon opened pull request #11426: BIP90: Make buried deployments slightly more easily extensible (master...e16-bip90-extensible) https://github.com/bitcoin/bitcoin/pull/11426
< jl2012>
gmaxwell: "technically we could make mainnet activate segwit at the same time as p2sh" not easy since miners included witness commitment before segwit activation. Those blocks are invalid under BIP141
< jonasschnelli>
sipa: re #11167, is it a problem that you can send to BIP173 addresses when IsWitness is diabled? "addwitnessaddress" rejects while sendtoaddress doesn't... I guess since it's active on mainnet this doesn't matter anymore?
2017-09-22
< achow101>
sipa: oh, ok. I don't see that in the BIPs though..
2017-09-21
< ThomasV>
gmaxwell: we were also considering an import format along the lines of bip124
< gmaxwell>
well sipa's bip173 patch doesn't have the error finder in it.
< gmaxwell>
jonasschnelli: another thing in the GUI is that we should eventually have a BIP173 error hinter. We need a monospace text entry field that can be told to underline characters or something like that.
< tloriato>
Hello! I was looking for how I could import a BIP32 Extended Key into the Bitcoin Core wallet? I've tried the RPC Documentation but got no luck there.
< gmaxwell>
(my motivator is primarily mining off blocksat, but this could eventually make a BIP152 HB mode like transmission smaller and faster too)
< BashCo>
I understand Core was in a tight spot re BIP148. People said it had to come from the users, and it did. Thankfully it was a great success.
< sontol>
had you kept mum about ASICBOOST and propose BIP149-like activation proposal animosity towards Bitmain won't go through the roof
< sontol>
Even if that will result in something that you don't plan for (e.g BIP148)
< OdaNobunaga>
I think it would be great to have a way of following core devs's discussions regarding protocol changes, like the table that listed devs' opinions regarding BIP148, 149, segwit2x etc.
< gmaxwell>
Says one thing, does another-- which will drive the headline; rather than the message of the complete arc which is user empowering. It'll just be "core backs down and does BIP9 anyways".
< OdaNobunaga>
Regarding the "will Core use BIP9 again" thing, I agree there's a huge disconnect between what the community (on slack and to a lesser extent reddit) thinks of what core will do (never do it again) vs. your idea of using BIP9 with BIP8 as fallback
< CodeShark>
perhaps BIP9 will be used again - but for now, BIP9 feels very demoralizing to many users
< gmaxwell>
Again, a direct response to BIP148 (they even said so in the announcement! :) )
< gmaxwell>
For example, one of your top contributors (who sent me some very nasty remarks) told me that Bitcoin Core was _never_ going to force a segwit activation and so BIP148 was the _only_ option.
< gmaxwell>
NYA was specifically created to take BIP148's success and turn it into something else.
< gmaxwell>
NYA wouldn't have even existed if not for BIP149.
< CodeShark>
bip8 would have allowed the nya to dominate headlines
< gmaxwell>
In doing it furthered a conflicting message. BIP9 was never 'miners choose'. It's just an activiation mechenism.
< gmaxwell>
CodeShark: I think people on slack echochambered themself into a corner about that. The obvious thing to do after BIP9 was BIP8, just as part of the process.
< CodeShark>
I think we all agree that BIP9 for segwit caused some serious problems
< CodeShark>
but if the situation changes, perhaps bip9 becomes viable again
< CodeShark>
things can always change. I think the overarching goal here is to convey that users choose consensus rules, not miners. and bip9 sends conflicting messages
< gmaxwell>
absolutely, but saying that we would not use BIP9 again is an error. I expect we would with an explicit stated outright plan to BIP8 after if user adoption was very strong but miners did not activate. These are technical details, sure. But unfortunately what got quoted was that BIP9 wouldn't be used again.
< CodeShark>
whether we use BIP8 or BIP9 or something else isn't nearly as important - although I do think it's important that users feel empowered to resist hostile miners
< gmaxwell>
CodeShark: that most of the slack people are effectively not involved in the project itself in any serious ongoing capacity, including not hanging out here. It has serious negative results, like you carrying around a we'd never use BIP9 message again, which is entirely not what I'm thinking and I doubt its what other people are thinking.
2017-09-12
< meshcollider>
morcos: by tripling, do you mean one P2PKH, one P2SH and one BIP173?
2017-09-10
< kanzure>
if a bip125-replaceable transaction's replacement does not have sufficient fee as defined by bip125, does the replacement become a valid replacement if the replacement gets a descendant that pays sufficient fee (child pays for parent)?
2017-09-09
< meshcollider>
I was only thinking about the security of importing the seed, not about bip44 itself hence my confusion
< gmaxwell>
BIP44 basically violates bip32 by applying public derrivation to all cases, it should only be used in cases where export is not permitted; which is plausable for hardware wallets.
< meshcollider>
as long as they support the same seed -> master key in bip32 and tree structure in bip44
< gmaxwell>
meshcollider: bip39 is a bad spec, disavowed by some of its authors even. Among other issues it has no facilities for versioning, which is a critical flaw.
2017-09-08
< jonasschnelli>
with a dummy key/address generated in bip32.org or so
< esotericnonsense>
from BIP141 i interpret 'base tx size' as tx.serialize() (because it is equivalent to tx.serialize_without_witness()), and tx.serialize_with_witness() as being total transaction size BIP141
< gmaxwell>
Esp for BIP173; the transition can't really be done abruptly unless its seriously delayed.
< instagibbs>
morcos, most are doing bip49 I think, which only is about nested
< gmaxwell>
sipa: we should have specified this as part of the segwit bips then. :( but okay, it could be done.
< gmaxwell>
why are we expanding scope to recieve BIP173 addresses. I think we should not make this scope expansion now.
2017-08-30
< instagibbs>
bip49, minus the bip44 part?
2017-08-29
< instagibbs>
ok, not knowledgeable enough to really dive into improvements, was having a discussion that revolved around bip125/Core design of replacement
< sipa>
luke-jr: with BIP152, the size hardly matters, except if you're ridiculously bandwidth constraint to the point you'd be unable to keep a node synced in the first place
2017-08-22
< rubensayshi>
yea Proposed sounds like the right status for BIP173 and for people to starting deploying (wallet support for) it
< sipa>
bip173 was written with many reference implementations at the time of publishing already, in the hope of not needing any significant change afterwards
< sipa>
rubensayshi: oh, BIP2 has a "proposed" status
< sipa>
rubensayshi: i think there have been too many cases of bips fundamentally changing after initial publishing
< rubensayshi>
yea which BIP2 addresses to prevent that from happening once they reach Final
< sipa>
rubensayshi: i personally have no intention of changing bip173 anymore
< rubensayshi>
but lets say BIP39 (*hint hint that actually did change under my feet while it was Final, but lets not side step too much*)
< rubensayshi>
hmm, when will BIP173 move from Draft to Final?
2017-08-16
< gmaxwell>
as any whitepeer would still be able to request anythign we have. (in your BIP150 world that phone would be authenticated, presumably)
< jonasschnelli>
(in an ideal BIP150 world)
< sipa>
so, i'd like to suggest that bip159 only defines 1 bit, corresponding to 144/288 blocks
< jonasschnelli>
last updates on BIP159: threat bits independently, fingerprinting protection
<@wumpus>
#topic bip159: (NODE_NETWORK_LIMITED service bits)
< sipa>
do we want to discuss bip159 more?
< gribble>
https://github.com/bitcoin/bitcoin/issues/10387 | Implement BIP159, define and signal NODE_NETWORK_LIMITED (pruned peers) by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
< * jonasschnelli>
puts Implement BIP159 / #10387 on the list
< praxeology>
Is it just BIP143 + SIGHASH_FORKID = 0x40 ?
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #10957: Avoid returning a BIP9Stats object with uninitialized values (master...bip9status) https://github.com/bitcoin/bitcoin/pull/10957
< bitcoin-git>
bitcoin/master 3eb53b8 practicalswift: Avoid returning a BIP9Stats object with uninitialized values...
< bitcoin-git>
bitcoin/master a46a671 MarcoFalke: Merge #10957: Avoid returning a BIP9Stats object with uninitialized values...
< luke-jr>
I assumed jonasschnelli meant implement BIP37 client-side
< gmaxwell>
yea, if we had BIP150 I wouldn't mind random extensions there even without bips. if you're only using it between trusted adjcencies the criteria is different.
< wumpus>
if not you'd have to wait for BIP150 (authentication)
< wumpus>
then again BIP37 works now, that's a point, step-by-step evolution usually means that things keep moving instead of being blocked by big moves
< jonasschnelli>
I guess there are still usecases for BIP37 once BIP150 is life (trusted peers)
< wumpus>
if only to be able to refer to it in bips.md and such
< jonasschnelli>
CodeShark: why would it get deprecated (you mean dep. bip37 in favor of client side filtering)?
< gmaxwell>
(not due to it itself, but due to increasing the scope of BIP37)
< jonasschnelli>
BIP151 encryption question: the current definition says, that encryption negotiation has to be done before the version handshake (I guess it makes sense to have the enc.negotiation first). But how should a peer know if the other peer supports BIP151. Try and reconnect? Service bit fetch-able via relay, seeds (meh!)?
< venzen>
My bad for not comprehending this sooner - I was somehow understanding "effective" block size limit increase from BIP141 and related explanations
< kallewoof>
sipa: since it kind of overlapped with BIP154 (anti-DoS via POW) I am interested in the work in replacing the misbehaving stuff with how useful a node has been that you mentioned before. Is there any work being done on this currently?
< kallewoof>
Will re-read BIPs though, while at it.
< sipa>
it's similar to BIP37's MSG_FILTERED_BLOCK btw
< gmaxwell>
we might end up inadvertantly rescuing them with a more rapid adoption of BIP173 though then there is the same idiocy that may happen four months from now. :( and maybe we should hold back posting the BIP173 integration from core so that it's distinct from the next of these dumb forks.
2017-08-03
< gmaxwell>
It also suggests that BIP173 support's test plan should include testing it with other witness version numbers. :)
< sipa>
so, bip173 specifies how to translate address strings to witness version/program, and defers to bip141 for encoding that to scriptPubKeys
< wumpus>
#topic bip173 unit tests issue
< sipa>
short topic: bip173 unit tests issue
< wumpus>
do we need any updates to bips.md for 0.15?
< luke-jr>
where are we at with a 0.14.3 with BIP148? I'm going to miss next meeting most likely again :/
2017-07-30
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10957: Do not return a BIP9Stats object with uninitialized values (master...bip9status) https://github.com/bitcoin/bitcoin/pull/10957
< sipa>
the fix for #10924 is easy: we need to add P2WSH/P2WPKH to CTxDestination, which is needed anyway for bip173 support
< gmaxwell>
BIP173 is worse becuase it's just not implemented at all... I wouldn't even suggest it except for the nice property of being able to say "any segwit version can send to BC addresses".
< jtimon>
so what about 0.15.1 -> segwit wallet, 0.15.2 - > send to bip173, optionally receive ?
< wumpus>
creating bip173 receiving addresses should be optional, to not confuse too much, especially as long as vrutally no other wallets have support for it
< gmaxwell>
jonasschnelli: BIP173 is native segwit, we have tests for native segwit... what BIP173 adds is just an address encoding for it, so that it can be made user accessible.
< gmaxwell>
jonasschnelli: we can recieve BIP173 payments with some hidden options. (I believe the code is still there-- we have tests for that already)
< wumpus>
sending obvs is optional in itself, you don't *need* tos send to BIP173 addresses, and if you do you know what you're doing. I mean about receiving.
< jonasschnelli>
BIP173 sending only is kinda hard(er) to test without the rec. part
< gmaxwell>
So there are two things I think are potential for scope, SW wallet (getnewaddress returns p2sh embedded SW), and BIP173 sending. We don't have to do them at the same time but it would be nice to be able to say that any SW enabled wallet can send to 173 style addresses.
< gmaxwell>
There are two questions: segwit wallet, and sending to BIP173. I consider the second less important, it's also more work (because it isn't already dormant in the codebase).
< gmaxwell>
BlueMatt: if we do BIP173 support it would just be sending to.
< gmaxwell>
to BIP173 style addresses. Maybe we could consider short cycling 0.16
2017-07-22
< morcos>
My general view is that the more we think the miners are going to properly enforce BIP91, the more we want to make a patch/release that does so
< praxeology>
BIP91 rules are not/never were my rules. I only heard about it yesterday when I was checking up on BIP 148 status
< btcdrak>
I agree this situation is ideal. If BIP91 had the same activation date as BIP148 it could have piggypacked and there would be significant node enforcement. But in 24 hours, I dont see how we can make this better at all. Asking exchanges et al to run a quick untested patch (by Core's standards) for what doesnt seem like an emergency (at least to me), seems irresponsible.
< btcdrak>
I've asked several pools and based on what they say at least, much more than 51% of the hashrate is running BIP91 enforcement code either btc1 or segsignal. They understand they must enforce the rule.
< luke-jr>
too many people disagree with the adjusted-BIP148 it seems, to reduce to a binary choice there
< luke-jr>
at least if it's simply BIP148 or non-BIP148, *users* will be on one or the other
< luke-jr>
gmaxwell: less likely than if 30% run BIP148-adapted-to-BIP91, 30% run BIP148-as-is, and 40% run non-BIP148
< luke-jr>
given the short time period and risk of splitting up enforcement too much, I currently favour just deployment of BIP148 as-is. not perfect, but I think it's the least-risky all things considered
< luke-jr>
gmaxwell: BIP148's patch is only larger for safety and unit tests. it's much smaller than BIP91 without those.
2017-07-21
< bitcoin-git>
[bitcoin] achow101 opened pull request #10900: [0.14] Enforce segsignal activation height and rules (0.14...early-uasf-bip91) https://github.com/bitcoin/bitcoin/pull/10900
< Murch>
praxeology: BIP91 requires every block to signal bit1.
< praxeology>
Emergency BIP91 Release
< [\\\]>
just as long as there is an info tip or link to what bip91 is
< sipa>
but the reason for having bip91 enforcement in the client is not to make a minority chain win