< December 2024 >
Su Mo Tu We Th Fr Sa 12345 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
2017-04-12
< arubi>
bip66 might be causing testnet failures where it works on regtest. will stop spamming :)
2017-04-11
< instagibbs>
jcorgan, some other repo's numbering of bip148
< jonasschnelli>
jcorgan: I have started with BIP151... sipa also mentioned he want to work on this
< bsm117532>
Is there any way for a BIP37 SPV client to obtain the coinbase transaction, if he doesn't know its txid?
2017-04-10
< jcorgan>
jonasschnelli: is there a bip150 work-in-progress branch anywhere?
2017-04-06
< jtimon>
so on the developer side, I think we can introduce a per-deployment optional field that makes a given deployment activate instead of expire according to bip9, I guess that deserves it's own bip even if it's a simple extension of bip9, but the code is also easy to add and not very disruptive, and it seems something reasonable to have
< jeremyrubin>
how does it break bip34?
< sipa>
well as long as you stick to the bip34 rules
2017-04-05
< bincap>
also, how to set given date of the block generation? I want to test bip148 that rejects blocks that do not signal for segwit activation
2017-04-04
< bsm117532>
My question is: does bitcoin consensus-enforce the statements in BIP16 about disallowing non-pushdata?
< wumpus>
emucode: as for existing tests, there's a test/functional/segwit.py and test/functional/bip9-softforks.py
< emucode>
btcdrak: I would like to write unit test, that creates a block, we assume that current date is 2016-09-01, and in this blog it sets on or off BIP9 flag, and segwit flag, and see if that block would be rejected or accepted
< emucode>
what commands available in test framework could be use for UT for BIP148?
2017-04-02
< bitcoin-git>
bitcoin/master 1f3d78b John Newbery: Wait for connection to open in bip9-softforks.py...
2017-03-26
< RealM9>
gmaxwell, I think you should review BIP148 only because of community interest. Okay, yes this BIP is only few weeks old, but why not? If there is a huge community interest, why not review it? Community is waiting for you to review. It's only few lines of code anyways. You don't have to put this BIP in next bitcoin core version. Just review it and sign binaries. People are fighting for SegWit. This would be a step further. You hav
2017-03-25
< gmaxwell>
In case "RealM9" comes back, I don't think anyone who regularly works on Bitcoin Core has even looked much at BIP148 yet.
< RealM9>
So, when will you sign BIP148 binaries?
2017-03-23
< gmaxwell>
Why are we even storing seralized private keys when BIP32 is in use?
< jonasschnelli>
Yes. An alternative for bip39?
2017-03-16
< gmaxwell>
stevenroose: no, it got 'activated' eons ago. then the miner signaling it mined BIP109 invalid blocks (because their implementation was broken) and forked classic off (until classic ripped out 109)
< stevenroose>
gmaxwell, yeah I read about bip109 as well when I googled the versionbit. So that means that 95% of testnett blocks the last few weeks were mined by people trolling about bip109?
< jonasschnelli>
The reminds me of the problem that BIP125 doesn't explicit mention a recommended nSequence nr. Electrum was using 0, Core intmax-2. (privacy)
< gmaxwell>
no, I think I'll just recommend no one use BIPs for anything. Process has failed.
< luke-jr>
a number of decent BIPs have negative comments; I suggest perhaps people may wish to provide positive feedback to counter them. https://github.com/bitcoin/bips/pull/500
2017-03-10
< bsm1175322>
Hmmm since you're here in NYC...we should get together soon and have a brainstorming session about a BIP37 replacement...
< bsm1175322>
Stage 2 of this project will be to redesign BIP37. I'm well aware of its flaws.
2017-03-09
< sipa>
jeremyrubin: BIP152 relay speed depends on having transactions in your mempool
< bitcoin-git>
bitcoin/master 9d5fcbf Wladimir J. van der Laan: Merge #9739: Fix BIP68 activation test...
< bitcoin-git>
bitcoin/master f5aba8a John Newbery: Move tx version 2 standardness check to after bip68 activation
< bitcoin-git>
bitcoin/master 99c0e81 John Newbery: Fix BIP68 activation test
2017-03-04
< gmaxwell>
the latest BIP152 stuff is much more policy durable than prior stuff, since it will retain transactions rejected for policy reasons and still use them to reconstruct blocks.
2017-03-03
< jonasschnelli>
I think it would be great if #9294 could get a review from on of the bip32 authors (ping sipa, gmaxwell)
< cannon-c>
I thought bip39 was just using dictionary wordlist in 2048 length list to convert 256 bit entropy to human readable words (256bit being 24 words)
< gmaxwell>
The workflow there is that they have a payment processing front end which generates keys using BIP32 public derrivation, and then imports the addresses. Because of contingencies around multiple nodes and restarts they may need to rescan a bit. The imported keys are used to watch for payments so they can display status to the user.
2017-02-13
< Chris_Stewart_5>
Looking at BIP113, it states we take the median time stamp for the last 11 blocks, but what stops the miner from egregiously lieing about that timestamp?
< gmaxwell>
need to stop saying RBF and just start saying BIP125 replacable. So much more clear. :P
< gmaxwell>
in any case before BIP152 spec was done, I tested prefill based on misses and it cut the rount trip rate by a ton... but it was on a dumb test network. debug=mempool logs enough to let you make the measurement with existing nodes.
< gmaxwell>
I doubt its much correlated with orphan risk at all now due to Fibre and BIP152.
2017-01-24
< sipa>
luke-jr: bumpfee won't let you bump without it being bip125
2017-01-20
< cfields>
sdaftuar: for the bip68-sequence test, i'm confused about how you tried to fix. Did you also try switching back to GetTime() rather than doubling down on GetTimeMicros()?
< CodeShark>
luke-jr: for BIP123, I think either CC0 or GNU-all-permissive
2017-01-19
< sipa>
(and for any other BIPs I contributed to)
< luke-jr>
sipa: if you get a minute, can you give me at least a text-"verbal" ACK for some copyright license to put on BIPs 30, 32, 62, 66, and 103 please? is BSD-2-Clause okay?
< gribble>
https://github.com/bitcoin/bitcoin/issues/9586 | bip68-sequence.py failing on master after recent net changes, due to mocktime interaction · Issue #9586 · bitcoin/bitcoin · GitHub
< NicolasDorier>
not yes thought about it. BIP9 I think the easiest at beginning is that the user does it. I plan in v1 that the user will pass the consensus flags to activate
< jtimon>
what about caches? what do you plan for caches? bip9 cache, sigcache?
< jtimon>
I was kind of doing that for 0.12 but I decided I would wait for bip9 and segwit instead
2017-01-07
< warren>
jonasschnelli: hmm, I'm excited to use your SPV mode in conjunction with BIP150 (authenticated connection to my own full nodes)
2017-01-05
< bitcoin-git>
bitcoin/master d29505d jonnynewbs: Fix transaction size comments. Size now refers to virtual size as defined in BIP141.
2017-01-04
< gmaxwell>
your concern is because we didn't really properly consider relaying unvalidated blocks, but we just glommed it on because it would have unfortunate to specify BIP152 another way.
2017-01-03
< gmaxwell>
and asking multiple peers is very inefficient with BIP37.. needs n-times the bandwidth.
< jonasschnelli>
Right, tx withhold is also possible with BIP37.
< gmaxwell>
I thought you were referring to the filter itselt and not the hash root... Unclear, multiple models are possible and _all_ are better than BIP37.
< jonasschnelli>
0-conf / spv should probably only be possible in conjunction with BIP150 and a trusted peer (at home or somewhere)
< jonasschnelli>
But I think there is no solution for a non-BIP37 0-conf "filtering" without running into these privacy issues related to bip37
< jonasschnelli>
In a long shot, I could imagine, BFD (filter digest / filter commitments) for filtering from untrusted peers, and BIP39 for filtering from trusted peers (once BIP150 has ben established).
< sipa>
BIP39?
< jonasschnelli>
Even if BIP39 is not the most efficient way.
2016-12-29
< Chris_Stewart_5>
Isn't there a chance for malleability in OP_CHECKMULTSIG scripts even with BIP146
< CodeShark>
I'll look into BIP152 a bit more after the meeting
< gmaxwell>
Sounds good. In any case, I'm glad to help talk it through. I wouldn't want to force you to wait on the BIP37 replacement to do something, but if we can be less stopgap that would be better.
< CodeShark>
extending BIP37 would be a stopgap measure at best - if we can deploy a better solution nearterm I'm all for it
< gmaxwell>
(in particular I was thinking you could use BIP37 on the non-witness data, and when you need witnesses, query by index for them)
< gmaxwell>
In any case, if CodeShark thinks many of the interesting usecases could be answered by a query by index... I would rather work on that first. I am realllly not eager to continue to invest in the pretty much known broken BIP37 approach.
< gmaxwell>
(I'm not sure you're familar with the BIP152 getblocktxn message, -- it is a "request transactions by their index in a block")
< CodeShark>
while I don't really like BIP37 at all, we currently lack another query mechanism that doesn't require full block downloads
< Chris_Stewart_5>
Why is this 'FindAndDelete' section needed in BIP143? Couldn't we just use FindAndDelete just like we did previously?
2016-12-16
< Chris_Stewart_5>
sipa: That made my night. I unequivocally support BIP42 and (while were at it) make PHP great again!
< Chris_Stewart_5>
ahh, BIP42, not BIP142. I was thinking there was a proposal for strange chars in segwit addresses
< sipa>
BIP32 also does not affect consensus, but it's still very useful to get people to agree on it
< sipa>
BIP42 suggests that the currency symbol color should be considered
< Chris_Stewart_5>
What do you think about raising the dbcache defeault value along the lines of your BIP10x proposal of scaling blocksize at the rate of tech growth (.. or something like that)
2016-12-15
< gmaxwell>
he's previously posted a number of absurd things, e.g. the posts claiming that BIP152 was going to "disrupt the network" and trying to get us to abort the 0.13 release.
< luke-jr>
BIPs 2 and 123 are now Active
2016-12-10
< btcdrak>
harrymm: BIP109 was marked rejected, so it's currently meaningless. You should contact them.
2016-12-08
< instagibbs>
morcos, that's too weeks of nodes not accepting fee bumps if you mess up and don't do bip125 (not sure how big an issue that is but still)
< jonasschnelli>
a flexible would allow to use bip44 and we could still stick to m/0'/k' by default
< jonasschnelli>
bip44/45 maybe. But I don't think its wise to force users to do pub key derivation.
< jcorgan>
i haven't kept up recently, but are there any relevant BIPS or defacto practices from other wallets we should be paying attention to in this area?
< gmaxwell>
Today, with BIP152 and fibre propagation has very little to do with blockmaxsize. And blockmaxweight is the wrong dimension for applying backpressure on fees: it's blind to demand, you'll still dumbly produce smaller blocks when there is a nice backlog and dumly produce blocks that are too big when there is none (at least the minfee stops the bleeding there)
< gmaxwell>
morcos: if you have debug=1 on, and the BIP152 missed by only a few txids it will log the missing txids and you can check your logs to see if you'd previously heard them.
< gmaxwell>
I'd like rejection to work differently, putting rejected things in a datastructure that works like the new sigcache open-hashtable where they're taged for eager eviction but kept around until actually evicted... and then BIP152 can use that pool, and orphan resolution can use it and so on.
< gmaxwell>
morcos: well we don't have the parent now and won't request it so the orphan will not get resolved. We might want to keep it around for BIP152 but right now BIP152 makes NO use of the orphan pool..
2016-12-01
< sipa>
there is work on a bumpfee command which will use bip125 to increase a txn's fee, and replace it with another one
< jtimon>
sipa: thanks, I'm not so familiar with the bip32 wallet
< gmaxwell>
jtimon: see bip32.. internal vs external.
< jonasschnelli>
jcorgan: bip32 internal and external chains
< jonasschnelli>
sipa: In case you once start with BIP150 (I know you'll wait until the net refactor has been completed), here is the extracted ChaCha20Poly1305AEAD code from openssh: https://github.com/jonasschnelli/chacha20poly1305
2016-11-29
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #9238: Ignore BIP35 mempool command by default (master...2016/11/dis_mempool) https://github.com/bitcoin/bitcoin/pull/9238
2016-11-27
< gmaxwell>
If in my efforts to contact users of the system or the mailing list thread had indicated that it wasn't universally (or nearly so) wanted, I would have opposed including it. The assumption is that it's wanted. Purpose of BIP9 is so that it will only happen once miners would actually enforce it.
< sipa>
dcousens: we don't want BIP9 to trigger if isn't actually enforced...
< dcousens>
if you signal though, it would still trigged BIP9 though?
< BashCo_>
I'm seeing people just look into the benefits for themselves instead of listening to bad info. Most people just want more tx capacity and they don't care about the details. Segwit will increase tx volume more than BIP109 and is backward compatible.
2016-11-26
< layman01>
bluematt, im looking while on here. but got interupted due to bip70 that didnt answer my question
< gmaxwell>
layman01: you've misunderstood BIP70.
< layman01>
ok so bip70 is still using the [output] part of a tx as the messaging tool (from my quick brief read of it) not adding data after [sig][nlocktime]
2016-11-23
< sipa>
bip151 changes the pipe, but the things being sent over it are still the same messages
< sipa>
i see bip151 simply as a change to the pipe, not to the messages in it
< cfields>
BlueMatt: i have a proposal for bip151 that would make it so that encryption isn't reliant on the messaging processing layer, but i haven't written it up yet
< gmaxwell>
for example, some peers might use compacted transactions some might not. But is that the correct layer for it? I don't think we'd propose implementing BIP152 block compaction inside CConnman.
< Chris_Stewart_5>
Is the serialization format described in BIP141 only used when calculating a wtxid, or is this serialization format also used when propogating a tx across the p2p network?
2016-11-18
< sipa>
gmaxwell: well if they don't support bip145, they will just ignore default_witness_commitment
< sipa>
cfields: maybe in bip151 the checksum should be at the end
2016-11-17
< jtimon>
BlueMatt: I guess if we can maintain the printing of the error without much disruption that would be nice, but I don't really know how important this is for bip22, maybe luke-jr has an opinion on this?
< Chris_Stewart_5>
jcorgan: I misinterpreted wumpus comment about 'not using' BIP37 in core as 'removing' it and apparently that triggered everyone ;). Thanks for the support though, some one has to ask the dumb questions :-)
< gmaxwell>
Maybe someday BIP37 goes away, but only if it were replaced with something better for the things that use it now. There are proposals but at the moment no one is actively working on them.
< bsm1175321>
I'm interested in making an update to BIP37 to improve light wallet security...
< jonasschnelli>
Chris_Stewart_5: </panic mode> you can use BIP37 with plenty of other wallets, but when using Core, we don't want scarifies privacy over because of some GB bandwidth
< wumpus>
we're just nopt using BIP37 for the light wallet mode in bitcoin core. If you want to use it in your wallet go ahead.
< wumpus>
no one is *removing* BIP37
< Chris_Stewart_5>
jonasschnelli: If we are removing BIP37 there isn't a choice.
< jonasschnelli>
I think it could have it's reason when connected to a BIP150 authed trusted peer. But only then.
< wumpus>
yes, BIP37 is a bad idea, we're not going to use it in core
< gmaxwell>
(BIP37 is also vulnerable to txn being hidden from you)
< jonasschnelli>
Chris_Stewart_5: its a safer solution then BIP37...
< Chris_Stewart_5>
This is alt solution to BIP37 then, or complementary?
< gmaxwell>
Chris_Stewart_5: bip37 _utterly_ destroys privacy, and would waste bandwidth if you're later going to need the block for verification anyways.
< Chris_Stewart_5>
sipa: "any BIP66-compliant non-empty byte array but not a valid signature" - this means that it is not a valid signature wrt to the public key in the script, right?
< Chris_Stewart_5>
The way I read BIP146, it's almost saying that you cannot place a OP_FALSE onto the stack unless OP_CHECKSIG had as input an empty byte array as a signature, but of course that doesn't make sense
< cfields>
jonasschnelli and i just discussed a bit, i'm making sure that the current refactors at least make bip151 not harder, but hopefully easier too
< sipa>
jonasschnelli: i was planning to work on bip151, but i'm not going to touch anything before the ongoing net refactors are done :)
< jonasschnelli>
I have started with the BIP151 implementation and are trying to split it into different PRs, though, not sure how easy that is.
2016-11-08
< jtimon>
wumpus: instagibbs I added the reindex rpc tests to #8994, to test #9102 (well, and #8994 in general), if you think of other rpc tests that would be interesting to duplicate for this or default values for the custom chain (ie maybe consensus.BIP34Height = 0 or whatever ) please let me know
2016-11-07
< instagibbs>
So I noticed that AcceptBlock attempts to validate various amounts of the genesisblock upon reindexing. Is this desired behavior? For example, it checks for height in coinbase if bip34height is set to <= 0
< murch>
Does signaling start with the epoch time listed in the Deployment on BIP141 or with the first difficulty retarget after the epoch time listed in deployment?
< luke-jr>
gmaxwell: I *think* we've fixed such issues in Final BIPs already
< gmaxwell>
If no one of consequence actually implemented BIP30 as specified in the doc, what use does keeping the old doc around (except in the git history) serve?
< gmaxwell>
morcos: so interesting point, say we discovered that BIP30 was implemented differently from the BIP tomorrow. What should we do? IETF way would be to attach an erratum to the document right away. But I find that this often confuses people who manage to read the document without an erratum. Then later a new document is published that reflects reality. Though this has a problem that people reme
< luke-jr>
sipa: sure, we still make clarifications to Final BIPs even now I think
< gmaxwell>
and BIP152 already explained how versions were to be handled in a compatible way.
< gmaxwell>
luke-jr: for the specifics here, 0.13.1 is compatible with BIP152 because it implements a new version number that the original bip152 was just silent on.
< gmaxwell>
But I think what luke was referring to is that BIP152 didn't originally document version 2 compact blocks that use the wtxid instead.
< sipa>
so i believe 0.13.1 is compliant with the updated bip152
< sipa>
so the issue is only when potential other bip152 implementations are oresent on the network
< luke-jr>
(suggested topic: when to halt changes to BIPs; 0.13.1 is no longer BIP 152-compatible I think)
2016-11-01
< sipa>
oh, with bip68 we do
< morcos>
bip68?
< jonasschnelli>
BIP152 doesn't helps in the SPV mode (UTXO set not ready)
< gmaxwell>
the timeout is 10 minutes. (at the tip, normally we expect things to be transfered via BIP152 high bandwidth mode, which can't stall)
2016-10-31
< sipa>
and the bip151 hasher should be a few times faster
< gmaxwell>
was it related to bip30?
2016-10-30
< goatpig>
wait so BIP142 isn't approved?
< goatpig>
what's the status on BIP142?
2016-10-29
< arubi>
at least that's what I gathered from bip141
2016-10-28
< gmaxwell>
tulip: I've encountered a number of other nodes doing that, wastes a lot of bandwidth. now that we have BIP152 deployed, we should look to banning peers that send unsolicited full blocks.
2016-10-27
< Chris_Stewart_5>
Not sure if this this is a good question or not, but is this something deployed with BIP9?
< jtimon>
like really imposing the 21 M limit, that was a softfork too, but no need to use bip9 to deploy I guess
< sipa>
only before bip34 activation
< NicolasDorier>
sipa: the thing that slow down is BIP30
< NicolasDorier>
while playing doing my node in C#, I tried a way to speedup IBD by 50%: Basically I prefetch the UTXO and tx id's (for BIP30) of block N+1 while validating block N. Still a bit early to call victory, but might be a piste to explore for core
2016-10-26
< michagogo>
btcdrak: I see that for the BIPs
2016-10-23
< wumpus>
well a new testnet would need a new bip70 identifier I guess so that can be fixed then... but it's a minor inconsequential thing
< jtimon>
I particularly hate the fact that in bip70 testnet3 is called "test" instead of "testnet3" but that's a tiny detail
< jtimon>
well, maybe if you want to make some values more similar to the mainnet to make them constants again, but I really don't know, I've thought more about testnet4, particularly in the context of bip70 which maybe gets replaced or something
< jl2012>
i think the main argument for BIP16 was the output is not anyone-can-spend until it is actually spent. But the difference is very limited
< wumpus>
segwit got *tons* of review compared to BIP16 I'm sure
2016-10-20
< sipa>
jtimon: my fear is that it's very hard to create a stable API for storage of headers... things like BIP9 cache and the skiplist for example are things that would break the API, but such changes may be needed in the future
< jtimon>
to hide the bip9 and previous developments stuff
< jtimon>
wumpus: like bip113 ? or more like bip30 ?
< Victorsueca>
maybe it would be better if we named bip147 something other than nulldummy
< sipa>
Victorsueca: bip147
< GitHub86>
[bitcoin] jonasschnelli reopened pull request #8723: [Wallet] Add support for flexible BIP32/HD keypath-scheme (master...2016/09/hd_flex) https://github.com/bitcoin/bitcoin/pull/8723
< GitHub145>
[bitcoin] jonasschnelli closed pull request #8723: [Wallet] Add support for flexible BIP32/HD keypath-scheme (master...2016/09/hd_flex) https://github.com/bitcoin/bitcoin/pull/8723
2016-10-19
< GitHub129>
bitcoin/master fc14609 mruddy: RPC: augment getblockchaininfo bip9_softforks data
< btcdrak>
yes, the fact BIP9 requires 4-6 weeks to kick in realistically, makes it less of an issue
< gmaxwell>
Keep in mind, in prior softforks the starting time was infinitely far in the past. And BIP9 made its way through 95% of its development with no starting time.
< sdaftuar>
i don't think we can just change bip9 params during the rc process
< wumpus>
#topic BIP9 parameters
< gmaxwell>
BIP9 recommends it be set roughly a month after software release. I don't currently see a reason to deviate from that.
< dcousens>
(assuming a transaction is to be encoded per BIP141), is witnesses length always == to inputs length? Just reading: "A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a 0x00."
< luke-jr>
indeed, node policy isn't something BIPs should cover, except in the case of it being preparation for a softfork
< gmaxwell>
Well we can do like we did with CSV, we had three BIPs triggered on one bit.
< sipa>
wumpus: i guess MSG_FILTERED_WITNESS_BLOCK is what we'd need for a bip37 extension with segwit data
< achow101>
the values for MSG_WITNESS_BLOCK and MSG_WITNESS_TX should probably be defined in BIP144...
< wumpus>
MSG_FILTERED_WITNESS_BLOCK defined in protocol.h is neither used in our source code nor defined in any BIP, should be in BIP144 I guess?
2016-10-03
< gmaxwell>
no, bips are for interoperability. the internal encoding is purely internal and could change freely from version to version.
2016-10-01
< luke-jr>
BIPs can't do both. maybe not relevant, dunno
< gmaxwell>
luke-jr: I had no idea about BIP2 until I wigged out about you assigning a BIP number to a restrictively licensed specification. :)
< MarcoFalke>
As I said, the BIP process does not make sense to be applied to BIP1 itself.
< luke-jr>
btcdrak: so you'd insist libbitcoin code cannot be used in any BIPs?
< luke-jr>
MarcoFalke: BIPs are amended by replacing them. That's how the process works right now. <.<
< MarcoFalke>
And then ping people: "Please read BIP2, BIP3, ... but don't read BIP1"...
< luke-jr>
so we can discourage people from adopting crappy BIPs
< MarcoFalke>
We should not forcefully keep us in this awkward situation of BIP1
< MarcoFalke>
I am looking forward to see the BIP2 changes merged, but there may be some people not approve all changes.
< MarcoFalke>
Sure, but for BIP1 it seems particularly weird. (Given that the (Github)user is not active in any other bitcoin related project)
< MarcoFalke>
I know BIP2 solves this, but we should use common sense to see that BIP1 mostly applies to other bips
< MarcoFalke>
luke-jr: It seems odd to place our whole bip process into the hands of a single github user. No one verified who owned this account right now. They could just do anything if they are required to ACK every change to BIP1.
2016-09-29
< achow101_>
so if anyone wants to help armory with segwit support, bip32, compressed keys, we accept PRs. All our work happens in the dev branch, not master
< achow101>
the plan is to have a new wallet structure with bip32 that supports segwit and compressed keys
< waxwing>
right, which i guess might be of particular import in your case (/me hasn't read bip151 tho)
< sipa>
implementing bip151 in wireshark will be fu
< wumpus>
a more practical way to go at this, post-bip151, would be add functionality to dump packets to disk after decryption on receive and before encryption on send, it's for debugging anyhow not snooping
< sipa>
damn. i believe this is a blocker for bip151.