Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
> On Sep 13, 2021, at 21:56, Anthony Towns wrote: > I'm not sure that's really the question you want answered? Of course it is? I’d like to understand the initial thinking and design analysis that went into this decision. That seems like an important question to ask when seeking changes in an existing system :). > Mostly > it's just "this is how mainnet works" plus "these are the smallest > changes to have blocks be chosen by a signature, rather than entirely > by PoW competition". > > For integration testing across many services, I think a ten-minute-average > between blocks still makes sense -- protocols relying on CSV/CLTV to > ensure there's a delay they can use to recover funds, if they specify > that in blocks (as lightning's to_self_delay does), then significant > surges of blocks will cause uninteresting bugs. Hmm, why would blocks coming quicker lead to a bug? I certainly hope no one has a bug if their block time is faster than per ten minutes. I presume here, you mean something like “if the node can’t keep up with the block rate”, but I certainly hope the benchmark for may isn’t 10 minutes, or really even one. > It would be easy enough to change things to target an average of 2 or > 5 minutes, I suppose, but then you'd probably need to propogate that > logic back into your apps that would otherwise think 144 blocks is around > about a day. Why? One useful thing for testing is compressing real time. More broadly, the only issues that I’ve heard around block times in testnet3 are the inconsistency and, rarely software failing to keep up at all. > We could switch back to doing blocks exactly every 10 minutes, rather > than a poisson-ish distribution in the range of 1min to 60min, but that > doesn't seem like that huge a win, and makes it hard to test that things > behave properly when blocks arrive in bursts. Hmm, I suppose? If you want to test that the upper bound doesn’t need to be 100 minutes, though, it could be 10. > Best of luck to you then? Nobody's trying to sell you on a subscription > plan to using signet. lol, yes, I’m aware of that, nor did I mean to imply that anything has to be targeted at a specific person’s requirements. Rather, my point here is that I’m really confused as to who the target user *is*, because we should be building products with target users in mind, even if those targets are often “me” for open source projects. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP extensions
On Wed, Sep 15, 2021 at 03:14:31PM +0900, Karl-Johan Alm via bitcoin-dev wrote: > BIPs are proposals. > It is then organically incorporated into the various entities that > exist in the Bitcoin space. At this point, it is not merely a > proposal, but a standard. Thinking of BIPs that have reach "Final" status as a "standard" might be reasonable, but I'd be pretty careful about even going that far, let alone further. But as you said, "BIPs are proposals". If your conclusion is somehow that a BIP "is not merely a proposal", you're reached a contradiction, which means you've made a logic error somewhere in between... > Someone may have > agreed to the proposal in its original form, but they may disagree > with it if it is altered from under their feet. > 2. To improve the proposal in some way, e.g. after discussion or after > getting feedback on the proposed approach. > 3. To add missing content, such as activation strategy. > I propose that changes of the second and third type, unless they are > absolutely free from contention, are done as BIP extensions. If you were proposing this just for BIPs that are marked final, then sure, maybe, I guess -- though why mark them final if you still want to add missing content or make further improvements? But if you want to apply it as soon as a BIP number is assigned or text is merged into the repo, I think that just means requesting number assignment gets delayed until the end of the development process rather than near the beginning, which doesn't sound particularly helpful. That's essentially how the lightning BOLTs are set up -- you only get to publish a BOLT after you've got support from multiple implementations [0]; but that has meant they don't have published docs for the various things individual teams have implemented, making interoperability harder rather than easier. There's been talk about creating bLIPs [1] to remedy this lack. > BIP extensions are separate BIPs that extend on or an existing BIP. So as an alternative, how about more clearly separating out draft BIPs from those in Active/Final state? ie: * brand new BIP draft comes in from its authors/champions/whatever * number xxx gets assigned, it becomes "Draft BIP xxx" * authors modify it as they see fit * once the authors are happy with the text, they can move it to Final status, at which point it is no longer a draft and is just "BIP xxx", and doesn't get modified anymore * go to step 1 (I'm doubtful that it's very useful to have an "Active" state as distinct from "Final"; that just gives the editors an excuse to play favourites by deciding whose objections count and whose don't (or perhaps which implementations count and which ones don't). It's currently only used for BIPs about the BIP process, which makes it seem particularly pointless...) > By making extensions to BIPs, rather than modifying them long after > review, we are giving the community [...] As described, I think you would be giving people an easy way to actively obstruct the BIP process by making it harder to "improve the proposal" and "add missing content", and encouraging contentiousness as a result. For adding on to BIPs that have reached Final status, I think just assigning completely new numbers is fine, as occurred with bech32 and bech32m (BIPs 173 and 350). Even beyond that, having BIP maintainers exercising judgement by trying to reserve/assign "pretty" numbers (like "BIP 3" for the new BIP process) seems like a mistake to me. If it were up to me, I'd make the setup be something like: * new BIP? make a PR, putting the text into "drafts/bip-authorname-description.mediawiki" (with corresponding directory for images etc). Have the word "Draft" appear in the "BIP: xxx" header as well as in the Status: header. * if that passes CI and isn't incoherent, it gets merged * only after the draft is already merged is a BIP number assigned. the number is chosen by a script, and the BIP maintainers rename it to "drafts/bip-xxx.mediawiki" in a followup commit including internal links to bip-authorname-description/foo.png and add it to the README (automatically at the same time as the merge, ideally) * when a BIP becomes Final, it gets moved from drafts/ into the main directory [2], and to avoid breaking external links, drafts/bip-xxx.mediawiki is changed to just have a link to the main doc. * likewise when a BIP becomes rejected/deprecated/whatever, it's moved into historical/ and drafts/bip-xxx.mediawiki and bip-xxx.mediawiki are updated with a link to the new location * otherwise, don't allow any modifications to bips outside of drafts/, with the possible exception of adding additional info in Acknowledgements or See also section or similar, adding Superseded-By: links, and updating additional tables that are deliberately designed to be updated, eg bip-0009/assignments.mediawiki It's better to remove incentives to introduce friction rather than add more.
Re: [bitcoin-dev] BIP extensions
Hi Frederico, Welcome to the bitcoin-dev list. :) Michael Folkson is currently pushing for a revision to BIP 2, which is discussed in the "BIP process meeting" thread here. You could help out by participating in that process. There's a wiki page with ideas for this in [1] and the current plan is to modify [2] or some other pull request to reflect what everyone decides. [1] https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist [2] https://github.com/bitcoin/bips/pull/1015 -Kalle. On Wed, 15 Sept 2021 at 17:29, Federico Berrone via bitcoin-dev wrote: > > Hi Karl-Johan, > I fully agree with your proposal. In order to de-clutter BIPs and make a > more understandable proposal, we can add the additional information in a > separate piece. Also, this would maintain the original proposal without > any modifications, showing the original spirit of it. > Let me know how can I help you with your proposal. > > Regards, > Federico Berrone. > > P/D: This is my first participation in the bitcoin-dev list, sorry if I > am breaking any rule, I would be glad to know if that is the case. > > El 15/09/2021 a las 8:14, Karl-Johan Alm via bitcoin-dev escribió: > > BIPs are proposals. > > > > They begin as ideas, are formulated and discussed on this list, and > > assuming no glaring flaws are observed, turned into pull requests to > > the bips repository, assigned a BIP number by the editors, and merged. > > > > It is then organically incorporated into the various entities that > > exist in the Bitcoin space. At this point, it is not merely a > > proposal, but a standard. As entities place their weight behind a BIP, > > it makes less and less sense to consider its author the "maintainer" > > of the BIP, with rights to modify it at their whim. Someone may have > > agreed to the proposal in its original form, but they may disagree > > with it if it is altered from under their feet. > > > > BIPs are modified for primarily three reasons: > > > > 1. Because of spelling errors, or to otherwise improve on their > > description without changing what is actually proposed. > > 2. To improve the proposal in some way, e.g. after discussion or after > > getting feedback on the proposed approach. > > 3. To add missing content, such as activation strategy. > > > > I propose that changes of the second and third type, unless they are > > absolutely free from contention, are done as BIP extensions. > > > > BIP extensions are separate BIPs that extend on or an existing BIP. > > BIP extensions do not require the approval of the extended-upon BIP's > > author, and are considered independent proposals entirely. A BIP that > > extends on BIP XXX is referred to as BIP-XXX-Y, e.g. BIP-123-1, and > > their introductory section must include the wording " > > > > This BIP extends on (link: BIP-XXX). > > > > ". > > > > By making extensions to BIPs, rather than modifying them long after > > review, we are giving the community > > 1. the assurance that a BIP will mostly remain in its form forever, > > except if an obvious win is discovered, > > 2. the ability to judge modifications to BIPs, such as activation > > parameters, on their merits alone, and > > 3. the path to propose modifications to BIPs even if their authors > > have gone inactive and cease to provide feedback, as is the case for > > many BIPs today, as BIP extensions do not require the approval of the > > extended-upon BIP. > > > > (Apologies if this has been proposed already. If so, feel free to > > ignore this message, and sorry to have wasted your time.) > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Reminder on the Purpose of BIPs
> I like the idea of decentralizing the BIPs process. It is a historical > artifact that the bips repository is part of the same organization that > bitcoin core is part of. But there shouldn't be the perception that > standardization is driven by that, or that there is any kind of (non-trivial) > gatekeeping. I had suggested few changes in BIP process and repository yesterday. Meeting was disappointing because of few reasons: 1.Its been 12 years since Bitcoin came in to existence and I am surprised that during such important conversations I still see only 4 people out of which 2 are maintainers. 2.None of the people who participated in meeting agree that we need to create multiple BIP directories and let people decide what works best for them. Reduce dependency on one repository or few people. At the end of the day these are just proposals, implementations are more important and there are so many ways to document things online, archive etc. Playing ACK/NACK game in 'bitcoin/bips' repository will be a waste of time so I created this as an example: https://github.com/prayank23/bips/blob/master/README.md https://prayank23.github.io/bips/ I respect everyone involved in Bitcoin development however neither I trust anyone nor I expect anyone to trust me. Bitcoin is not just another open source software. Its a protocol for decentralized network which can be used to settle payments. We are trying to redefine MONEY, many cypherpunks, activists, hacktivists, privacy advocates etc. are involved and trying to separate money from state. The same money that is needed for almost everything you do in this world from birth to death, love to war and same money that makes some people more powerful. So, I won't be surprised with anything in future and will be prepared for everything. -- Prayank A3B1 E430 2298 178F ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP extensions
Hi Karl-Johan, I fully agree with your proposal. In order to de-clutter BIPs and make a more understandable proposal, we can add the additional information in a separate piece. Also, this would maintain the original proposal without any modifications, showing the original spirit of it. Let me know how can I help you with your proposal. Regards, Federico Berrone. P/D: This is my first participation in the bitcoin-dev list, sorry if I am breaking any rule, I would be glad to know if that is the case. El 15/09/2021 a las 8:14, Karl-Johan Alm via bitcoin-dev escribió: BIPs are proposals. They begin as ideas, are formulated and discussed on this list, and assuming no glaring flaws are observed, turned into pull requests to the bips repository, assigned a BIP number by the editors, and merged. It is then organically incorporated into the various entities that exist in the Bitcoin space. At this point, it is not merely a proposal, but a standard. As entities place their weight behind a BIP, it makes less and less sense to consider its author the "maintainer" of the BIP, with rights to modify it at their whim. Someone may have agreed to the proposal in its original form, but they may disagree with it if it is altered from under their feet. BIPs are modified for primarily three reasons: 1. Because of spelling errors, or to otherwise improve on their description without changing what is actually proposed. 2. To improve the proposal in some way, e.g. after discussion or after getting feedback on the proposed approach. 3. To add missing content, such as activation strategy. I propose that changes of the second and third type, unless they are absolutely free from contention, are done as BIP extensions. BIP extensions are separate BIPs that extend on or an existing BIP. BIP extensions do not require the approval of the extended-upon BIP's author, and are considered independent proposals entirely. A BIP that extends on BIP XXX is referred to as BIP-XXX-Y, e.g. BIP-123-1, and their introductory section must include the wording " This BIP extends on (link: BIP-XXX). ". By making extensions to BIPs, rather than modifying them long after review, we are giving the community 1. the assurance that a BIP will mostly remain in its form forever, except if an obvious win is discovered, 2. the ability to judge modifications to BIPs, such as activation parameters, on their merits alone, and 3. the path to propose modifications to BIPs even if their authors have gone inactive and cease to provide feedback, as is the case for many BIPs today, as BIP extensions do not require the approval of the extended-upon BIP. (Apologies if this has been proposed already. If so, feel free to ignore this message, and sorry to have wasted your time.) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev OpenPGP_0xB4B16B2D677120AF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode
On Sun, Sep 12, 2021 at 07:37:56PM -0400, Antoine Riard via bitcoin-dev wrote: > While MERKLESUB is still WIP, here the semantic. [...] > I believe this is matching your description and the main difference compared > to > your TLUV proposal is the lack of merkle tree extension, where a new merkle > path is added in place of the removed tapscript. I think " MERKLESUB" is the same as " OP_0 2 TLUV", provided happens to be the same index as the current input. So it misses the ability to add branches (replacing OP_0 with a hash), the ability to preserve the current script (replacing 2 with 0), and the ability to remove some of the parent paths (replacing 2 with 4*n); but gains the ability to refer to non-corresponding outputs. > > That would mean anyone who could do a valid spend of the tx could > > violate the covenant by spending to an unencumbered witness v2 output > > and (by collaborating with a miner) steal the funds. I don't think > > there's a reasonable way to have existing covenants be forward > > compatible with future destination addresses (beyond something like CTV > > that strictly hardcodes them). > That's a good catch, thanks for raising it :) > Depends how you define reasonable, but I think one straightforward fix is to > extend the signature digest algorithm to encompass the segwit version (and > maybe program-size ?) of the spending transaction outputs. That... doesn't sound very straightforward to me; it's basically introducing a new covenant approach, that's getting fixed into a signature, rather than being a separate opcode. I think a better approach for that would be to introduce the opcode (eg, PUSH_OUTPUT_SCRIPTPUBKEY, and SUBSTR to be able to analyse the segwit version), and make use of graftroot to allow a signature to declare that it's conditional on some extra script code. But it feels like it's going a bit off topic. > > Having the output position parameter might be an interesting way to > > merge/split a vault/pool, but it's not clear to me how much sense it > > makes sense to optimise for that, rather than just doing that via the key > > path. For pools, you want the key path to be common anyway (for privacy > > and efficiency), so it shouldn't be a problem; but even for vaults, > > you want the cold wallet accessible enough to be useful for the case > > where theft is attempted, and maybe that's also accessible enough for > > the ocassional merge/split to keep your utxo count/sizes reasonable. > I think you can come up with interesting contract policies. Let's say you want > to authorize the emergency path of your pool/vault balances if X happens (e.g > a > massive drop in USDT price signed by DLC oracles). You have (A+B+C+D) forking > into (A+B) and (C+D) pooled funds. To conserve the contracts pre-negotiated > economic equilibrium, all the participants would like the emergency path to be > inherited on both forks. Without relying on the key path interactivity, which > is ultimately a trust on the post-fork cooperation of your counterparty ? I'm not really sure what you're saying there; is that any different to a pool of (A and B) where A suddenly wants to withdraw funds ASAP and can't wait for a key path signature? In that case A authorises the withdrawal and does whatever she wants with the funds (including form a new pool), and B remains in the pool. I don't think you can reliably have some arbitrary subset of the pool able to withdraw atomically without using the key path -- if A,B,C,D have individual scripts allowing withdrawal, then there's no way of setting the tree up so that every pair of members can have their scripts cut off without also cutting off one or both of the other members withdrawal scripts. If you know in advance which groups want to stick together, you could set things up as: (((A, B), AB), C) where: A = "A DUP H(B') 10 TLUV CHECKSIG" -> (B', C) B = "B DUP H(A') 10 TLUV CHECKSIG" -> (A', C) A' = "A DUP 0 2 TLUV CHECKSIG" -> (C) B' = "B DUP 0 2 TLUV CHECKSIG" -> (C) AB = "(A+B) DUP 6 TLUV CHECKSIG -> (C) C = "C DUP 0 2 TLUV CHECKSIG" -> ((A,B), AB) (10 = 2+4*2 = drop my script, my sibling and my uncle; 6 = 2+4*1 = drop my script and my sibling; 2 = drop my script only) Which would let A and B exit together in a single tx rather than needing two transactions to exit separately. > > Saving a byte of witness data at the cost of specifying additional > > opcodes seems like optimising the wrong thing to me. > I think we should keep in mind that any overhead cost in the usage of a script > primitive is echoed to the user of off-chain contract/payment channels. If the > tapscripts are bigger, your average on-chain spends in case of non-cooperative > scenarios are increased in consequence, and as such your fee-bumping reserve. > Thus making those systems less economically accessible. If you're worried about the cost of a single byte of witness data you probably can't afford to do script path spends at all --
[bitcoin-dev] BIP extensions
BIPs are proposals. They begin as ideas, are formulated and discussed on this list, and assuming no glaring flaws are observed, turned into pull requests to the bips repository, assigned a BIP number by the editors, and merged. It is then organically incorporated into the various entities that exist in the Bitcoin space. At this point, it is not merely a proposal, but a standard. As entities place their weight behind a BIP, it makes less and less sense to consider its author the "maintainer" of the BIP, with rights to modify it at their whim. Someone may have agreed to the proposal in its original form, but they may disagree with it if it is altered from under their feet. BIPs are modified for primarily three reasons: 1. Because of spelling errors, or to otherwise improve on their description without changing what is actually proposed. 2. To improve the proposal in some way, e.g. after discussion or after getting feedback on the proposed approach. 3. To add missing content, such as activation strategy. I propose that changes of the second and third type, unless they are absolutely free from contention, are done as BIP extensions. BIP extensions are separate BIPs that extend on or an existing BIP. BIP extensions do not require the approval of the extended-upon BIP's author, and are considered independent proposals entirely. A BIP that extends on BIP XXX is referred to as BIP-XXX-Y, e.g. BIP-123-1, and their introductory section must include the wording " This BIP extends on (link: BIP-XXX). ". By making extensions to BIPs, rather than modifying them long after review, we are giving the community 1. the assurance that a BIP will mostly remain in its form forever, except if an obvious win is discovered, 2. the ability to judge modifications to BIPs, such as activation parameters, on their merits alone, and 3. the path to propose modifications to BIPs even if their authors have gone inactive and cease to provide feedback, as is the case for many BIPs today, as BIP extensions do not require the approval of the extended-upon BIP. (Apologies if this has been proposed already. If so, feel free to ignore this message, and sorry to have wasted your time.) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
