Re: [bitcoin-dev] BIP number request for wallet policies
Just to inform this list, this pull request has since been assigned a BIP number (BIP 388) [0]. Thanks Michael [0]: https://github.com/bitcoin/bips/pull/1389 -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Saturday, 16 December 2023 at 14:10, Antoine Poinsot via bitcoin-dev wrote: > Wallet policies, a standard for implementing support for output descriptors > in hardware signing devices was introduced by Salvatore Ingala a year and a > half ago [0]. > > A pull request to the BIP repository was opened more than a year ago [1]. > It's been waiting for a BIP number to be assigned since then. > > There is now 3 majors hardware signing devices using this standard in > production (Ledger, BitBox02, Jade). There has been multiple pings on the PR > in the past year to get assigned a BIP number. > > It would be nice to hear from the BIP editors about their expectations from > the author, so we can move forward with this document specifying what's > already become an industry standard. > > Antoine Poinsot > > [0] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020492.html > [1] https://github.com/bitcoin/bips/pull/1389 > ___ > 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] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
Hi Peter Interesting post. By implicitly committing in advance to the fee paid by the spending transaction CTV is certainly nailing its colors to the CPFP mast rather than operating in a RBF world. And in a future high fee environment (ignoring whatever is driving those high fees, monetary or non-monetary use cases) as you state paying for an additional CPFP transaction is suboptimal rather than just replacing an existing unconfirmed transaction. I did a cursory search to look for an in depth technical comparison of CPFP and RBF and I found this from Antoine (Poinsot) on Bitcoin StackExchange [0]. In that he states his view that: "If most nodes didn't enforce mandatory BIP125 signalling, RBF would be superior in all aspects to CPFP from the perspective of the emitter of transaction. CPFP is much less efficient, and not always possible: you need the transaction to have a change output and (at least at the time of writing [0]) the parent to pass policy checks on its own, for instance if it's below the minimum feerate of most mempools on the network you won't be able to CPFP it at the moment." I assume that a CTV based LN-Symmetry also has this drawback when compared to an APO based LN-Symmetry? In theory at least an APO based LN-Symmetry could change the fees in every channel update based on what the current market fee rate was at the time of the update. In today's pre LN-Symmetry world you are always going to have justice transactions for revoked states that were constructed when the market fee rate was very different from the present day's market fee rate. Thanks Michael [0]: https://bitcoin.stackexchange.com/questions/117703/comparison-between-cpfp-and-bip125-for-fee-bumping -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Wednesday, 24 January 2024 at 19:31, Peter Todd via bitcoin-dev wrote: > CheckTemplateVerify(1) is a proposed covenant opcode that commits to the > transaction that can spend an output. Namely, # of inputs, # of outputs, > outputs hash, etc. In practice, in many if not most CTV use-cases intended to > allow multiple parties to share a single UTXO, it is difficult to impossible > to > allow for sufficient CTV variants to cover all possible fee-rates. It is > expected that CTV would be usually used with anchor outputs to pay fees; by > creating an input of the correct size in a separate transaction and including > it in the CTV-committed transaction; or possibly, via a transaction sponsor > soft-fork. > > This poses a scalability problem: to be genuinely self-sovereign in a protocol > with reactive security, such as Lightning, you must be able to get > transactions > mined within certain deadlines. To do that, you must pay fees. All of the > intended exogenous fee-payment mechanisms for CTV require users to have at > least one UTXO of suitable size to pay for those fees. > > This requirement for all users to have a UTXO to pay fees negates the > efficiency of CTV-using UTXO sharing schemes, as in an effort to share a UTXO, > CTV requires each user to have an extra UTXO. The only realistic alternative > is > to use a third party to pay for the UTXO, eg via a LN payment, but at that > point it would be more efficient to pay an out-of-band mining fee. That of > course is highly undesirable from a mining centralization perspective.(2) > > Recommendations: CTV in its current form be abandoned as design foot-gun. > Other > convenant schemes should be designed to work well with replace-by-fee, to > avoid > requirements for extra UTXOs, and to maximize on-chain efficiency. > > 1) > https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355bf6d7e7605/bip-0119.mediawiki > 2) > https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are-a-danger-to-mining-decentralization > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ > 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] BIP process friction
Thanks for this Peter, really helpful. > It is a much more fundamental standard than Ordinals or Taproot Assets, in the sense that transaction replacement is expected to be used by essentially all wallets as all wallets have to deal with fee-rate fluctuations; I do not think that Ordinals or Taproot assets are appropriate BIP material due to their niche use-case. Yes I'd personally lean towards this view too. Certainly when you go into alternative asset territory (e.g. Counterparty, Liquid (Network) assets, Taproot assets) it is moving away from what you can do with the Bitcoin asset/currency and into building a new ecosystem with a different asset/currency. I would agree that that should probably be out of scope for *Bitcoin* Improvement Proposals without having any particular opinion on the utility of any of those ecosystems. > just the other day I ran into someone that didn't know RBF Rule #6 existed, which Core added on top of BIP-125, and had made a mistake in their safety analysis of a protocol due to that. I suspected this might be the case but to actually have a data point to back that up (beyond I personally find it unnecessarily confusing and hard to follow) is helpful, thanks. > Finally, I think the lesson to be learned here is that mempool policy is > better served by *living* documentation that gets updated to reflect the real world. There's no easy way for someone to get up to speed on what mempool policy is actually implemented, and more importantly, *why* it is implemented and what trade-offs were made to get there. It's quite possible that this "living documentation" requirement rules out the BIP process. I get the "living", evolving point. Policy proposals are definitely different to say consensus proposals where assuming they are ever activated you'd expect them to stay static for the rest of Bitcoin's existence barring minor cleanups, clarifications etc. However, one possible addition in a new BIP 3 process would be the introduction of versioning for a particular BIP e.g. BIP 789 version 2 which would be more conducive to these evolving proposals such as policy proposals. You could then update a BIP without needing a new BIP number for every material update. I'll wait to hear what Luke thinks on this. Beyond the friction concern I think improving the BIP process for consensus and policy proposals would be the biggest potential win for a BIP 3 update. Thanks also to Kalle too for his 18 month stint as a BIP editor :) -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Thursday, 18 January 2024 at 18:00, Peter Todd wrote: > On Wed, Jan 17, 2024 at 05:29:48PM +, Michael Folkson via bitcoin-dev > wrote: > > > Hey Luke > > > > I'd be happy to pick up working on BIP 3 again ([0], [1]) in light of this > > issue and others that are repeatedly cropping up (e.g. confusion on the > > recommended flow for working on proposed consensus changes, when to open a > > pull request to bitcoin-inquisition, when to open a pull request to Core, > > when to include/exclude activation params etc). > > > > I don't think there is much I personally disagree with you on with regards > > to BIPs but one issue where I do think there is disagreement is on whether > > proposed default policy changes can/should be BIPed. > > > > I previously drafted this on proposed default policy changes [2]: > > > > "To address problems such as pinning attacks on Lightning and multiparty > > protocols (e.g. vaults) there are and will continue to be draft proposals > > on changing the default policy rules in Bitcoin Core and/or alternative > > implementations. As these proposals are for default policy rules and not > > consensus rules there is absolutely no obligation for Bitcoin Core and/or > > alternative implementations to change their default policy rules nor users > > to run any particular policy rules (default or otherwise). The authors of > > these draft proposals are clearly recommending what they think the default > > policy rules should be and what policy rules users should run but it is > > merely a recommendation. There are a lot of moving parts, subtleties and > > complexities involved in designing default policy rules so any > > recommendation(s) to significantly upgrade default policy rules would > > benefit from being subject to a spec process. This would also aid the > > review of any policy related pull requests in Bitcoin Co re and/or alternative implementations. An interesting recent case study washttps://github.com/bitcoin/bitcoin/pull/22665and Bitcoin Core not implem
Re: [bitcoin-dev] MuSig2 derivation, descriptor, and PSBT field BIPs
Hi Christopher In the absence of a response from someone who is working on MuSig2/FROST etc I did ask Tim Ruffing about the problems with using x-only pubkeys for MuSig2 etc in an (online) London Bitcoin Devs meetup [0] in 2022. His response was: "If you want to do more complex things, for example MuSig or more complex crypto then this bit is always a little pain in the ass. We can always get around this but whenever we do advanced stuff like tweaking keys, a lot of schemes involve tweaking keys, even Taproot itself involves tweaking, MuSig2 has key aggregation and so on. You always have to implicitly remember that bit because it is not explicitly there. You have to implicitly remember it sometimes. This makes specifications annoying. I don’t think it is a problem for security but for engineering it is certainly annoying. In hindsight it is not clear if we would make that decision again. I still think it is good because we save a byte but you can also say the increased engineering complexity is not worth it. At this point I can understand both points of view." Hope this helps. Thanks Michael [0]: https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340 -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Tuesday, 16 January 2024 at 08:18, Christopher Allen via bitcoin-dev wrote: > On Mon, Jan 15, 2024 at 4:28 PM Ava Chow via bitcoin-dev > wrote: > >> I've also made a change to the PSBT fields BIP where the aggregate >> pubkey is included as a plain pubkey rather than as xonly. I think this >> change is necessary for to make discovering derived keys easier. The >> derivation paths for derived keys contain the fingerprint of the parent >> (i.e. the aggregate pubkey) and the fingerprint requires the evenness >> bit to be serialized. So the aggregate pubkey in the PSBT fields need to >> contain that evenness information in order for something looking at only >> the PSBT to be able to determine whether a key is derived from an >> aggregate pubkey also specified in the PSBT. > > The topic of some challenges in using x-only pubkeys with FROST recently came > up in a conversation that I didn't completely understand. It sounds like it > may be related to this issue with MuSig2. > > What are the gotcha's in x-only keys with these multisig protocols? Can you > explain a little more? Any other particular things do we need to be careful > about with x-only pubkeys? I had mistakenly assumed the technique was just a > useful trick, not that it might cause some problems in higher level protocols. > > Thanks! > > -- Christopher Allen___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP process friction
Hey Luke I'd be happy to pick up working on BIP 3 again ([0], [1]) in light of this issue and others that are repeatedly cropping up (e.g. confusion on the recommended flow for working on proposed consensus changes, when to open a pull request to bitcoin-inquisition, when to open a pull request to Core, when to include/exclude activation params etc). I don't think there is much I personally disagree with you on with regards to BIPs but one issue where I do think there is disagreement is on whether proposed default policy changes can/should be BIPed. I previously drafted this on proposed default policy changes [2]: "To address problems such as pinning attacks on Lightning and multiparty protocols (e.g. vaults) there are and will continue to be draft proposals on changing the default policy rules in Bitcoin Core and/or alternative implementations. As these proposals are for default policy rules and **not** consensus rules there is absolutely no obligation for Bitcoin Core and/or alternative implementations to change their default policy rules nor users to run any particular policy rules (default or otherwise). The authors of these draft proposals are clearly recommending what they think the default policy rules should be and what policy rules users should run but it is merely a recommendation. There are a lot of moving parts, subtleties and complexities involved in designing default policy rules so any recommendation(s) to significantly upgrade default policy rules would benefit from being subject to a spec process. This would also aid the review of any policy related pull requests in Bitcoin Core and/or alternative implementations. An interesting recent case study washttps://github.com/bitcoin/bitcoin/pull/22665and Bitcoin Core not implementing the exact wording of BIP 125 RBF. In this case (for various reasons) as a response Bitcoin Core just removed references to BIP 125 and started documenting the replacement to BIP 125 rules in the Bitcoin Core repo instead. However, it is my view that recommendations for default policy rules should be recommendations to all implementations, reviewed by Lightning and multiparty protocol developers (not just Bitcoin Core) and hence they would benefit from being standardized and being subject to a specification process. I will reiterate once again though that policy rules are **not** consensus rules. Consensus rules are much closer to an obligation as divergences from consensus rules risk the user being forked off the blockchain and could ultimately end up in network splits. This does not apply to policy rules." Are you open to adjusting your stance on proposed policy changes being BIPed? I do think it really stunts work on proposed default policy changes and people's ability to follow work on these proposals when the specifications for them are littered all over the place. I've certainly struggled to follow the latest state of V3 policy proposals without clear reference points for the latest state of these proposals e.g. [3]. In addition some proposed consensus change BIPs are starting to want to include sections on policy (e.g. BIP345, OP_VAULT [4]) where it would be much better if they could just refer to a separate policy BIP rather than including proposals for both policy and consensus in the same BIP. Thanks for your long and continued work on the BIP process. It is thankless work and we don't see the alternative futures where all sorts of garbage was merged and given BIP numbers because the BIP editors just merged everything without looking at it and not caring about quality standards. Thanks Michael [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019412.html [1]: https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist [2]: https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist#default-policy-changes-eg-v3-a-recommendation-but-not-an-obligation-for-bitcoin-implementations [3]: https://bitcoin.stackexchange.com/questions/117315/what-and-where-are-the-current-status-of-the-bip-125-replacement-the-v3-policy [4]: https://github.com/bitcoin/bips/pull/1421 -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Wednesday, 17 January 2024 at 16:45, Luke Dashjr via bitcoin-dev wrote: > Perhaps a BIP 3 is in order, but most of the real issue is simply a matter of > volunteer time. > > AJ's attempt to conflate that with his own personal disagreements with how > BIPs have always worked, is unrelated. > > Luke > > On 1/17/24 01:55, Christopher Allen via bitcoin-dev wrote: > >> On Tue, Jan 16, 2024 at 6:43 PM Anthony Towns via bitcoin-dev >> wrote: >> >>> If people want to use it for bitcoin-related proposals that don't have >>> anything to do with inquisition, that's fine; I'm intending to apply the >>> policies I think the BIPs repo should be us
Re: [bitcoin-dev] Swift Activation - CTV
In the interests of time I'll just pick two to respond to but I don't agree with any of your points. > Covenants allow trustless utxos sharing and also are needed for vaulting. The > numerous use cases are documented, built out and on signet to my knowledge. > Check out[utxos.org](http://utxos.org/)for a good list Your knowledge is incorrect. As far as I know in the getting on for 2 years since the first CTV activation talk/attempt literally no one has built out a CTV use case and demonstrated it on signet with the possible exception of James O'Beirne's OP_VAULT which requires other new opcodes in addition to CTV. I wish this wasn't the case. It is pitiful that we have these individuals (such as yourself) that are so convinced CTV should be activated but refuse to address any concerns raised by others and refuse to work on any of the speculated use cases, instead choosing to just beat the activation drum over and over again. > 4. "Best tool for the job" is not the bar. "Safe for all" and "useful for > some" is the bar. Like any opcodes or tech Bitcoin has deployed in the past. > Changing the bar is not up for discussion. If you want to avoid a chain split with an activation attempt (it is possible you don't care but if you do) you have to address concerns others have with a particular proposal. Just because Satoshi was able to make whatever changes he liked in the early days of Bitcoin's history and smaller groups of contributors then were able to activate changes without much scrutiny (Bitcoin was worth a fraction of what it is today and was only supporting a tiny ecosystem back then) doesn't mean we can do the same today. Appointing Erik as the new Satoshi who can make whatever changes he likes, who defines the bar with ultimate certainty and decides what is and what isn't up for discussion also isn't a viable option. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Monday, 1 January 2024 at 17:11, Erik Aronesty wrote: > 1. Claiming that something that isn't activated (unusable) isn't used as a > non-argument > > 2. Talking about activation methods is orthogonal. Bip8 is fine. > > 3. Covenants allow trustless utxos sharing and also are needed for vaulting. > The numerous use cases are documented, built out and on signet to my > knowledge. Check out utxos.org for a good list > > 3. No need to discuss wild extremes that are unrelated to ctvs well > documented utility. Plus multi-sig allows governments to encumber (or > accidentally ruin) destination addresses just like covenants. > > 4. "Best tool for the job" is not the bar. "Safe for all" and "useful for > some" is the bar. Like any opcodes or tech Bitcoin has deployed in the past. > Changing the bar is not up for discussion. > > CTV has already been demonstrated "useful for some". The question that needs > to be answered is whether there are any specific objections to safety. > > On Mon, Jan 1, 2024, 11:37 AM Michael Folkson > wrote: > >> Hi Erik >> >>> So what exactly are the risks of CTV over multi-sig? >> >> It is a strange comparison. Multisig is active onchain and is being used >> today for all sorts of things including Lightning and setups that address >> risk of single key loss or malicious signing. When discussing risks of CTV >> there are all sorts of risks that don't apply to multisig. These include >> that it is never used for any of its speculated use cases (multisig is being >> used today), other proposals end up being used instead of it (I'm not sure >> there were or are competing proposals so that multisig stops being used, >> MuSig2 maybe?), chain split risks with activation if there isn't consensus >> to activate it etc. Plus usage of complex (non covenant) scripts that fully >> utilize Taproot trees is still low today. Going straight to covenants >> (imposing restrictions on where funds can be sent) and not bothering with >> imposing all the restrictions you'd like on how funds can be spent in the >> first place seems to me to be putting the cart before the horse. Covenants >> don't ultimately solve the key management issue, they just move it from the >> pre spending phase to the post spending phase. So the benefits (although >> non-zero) aren't as obvious as some of the covenant advocates are >> suggesting. And although CTV is a limited covenant (some argue too limited) >> covenants taken to wild extremes could create all sorts of second order >> effects where funds can't be spent because of complex combinations of >> covenants. Even the strongest CTV proponent seems to suggest that the >> introduction of covenants wouldn't end with CTV. >> >> The way to reduce implementation risk for a use case of a particular >> proposal is to build out that use case and see if CTV is the best tool for >> the job. Repeatedly try
Re: [bitcoin-dev] Swift Activation - CTV
Hi Erik > So what exactly are the risks of CTV over multi-sig? It is a strange comparison. Multisig is active onchain and is being used today for all sorts of things including Lightning and setups that address risk of single key loss or malicious signing. When discussing risks of CTV there are all sorts of risks that don't apply to multisig. These include that it is never used for any of its speculated use cases (multisig is being used today), other proposals end up being used instead of it (I'm not sure there were or are competing proposals so that multisig stops being used, MuSig2 maybe?), chain split risks with activation if there isn't consensus to activate it etc. Plus usage of complex (non covenant) scripts that fully utilize Taproot trees is still low today. Going straight to covenants (imposing restrictions on where funds can be sent) and not bothering with imposing all the restrictions you'd like on how funds can be spent in the first place seems to me to be putting the cart before the horse. Covenants don't ultimately solve the key management issue, they just move it from the pre spending phase to the post spending phase. So the benefits (although non-zero) aren't as obvious as some of the covenant advocates are suggesting. And although CTV is a limited covenant (some argue too limited) covenants taken to wild extremes could create all sorts of second order effects where funds can't be spent because of complex combinations of covenants. Even the strongest CTV proponent seems to suggest that the introduction of covenants wouldn't end with CTV. The way to reduce implementation risk for a use case of a particular proposal is to build out that use case and see if CTV is the best tool for the job. Repeatedly trying to activate CTV when there isn't consensus for it to be activated does not reduce that implementation risk in any way, shape or form. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Saturday, 30 December 2023 at 08:59, Erik Aronesty via bitcoin-dev wrote: > So what exactly are the risks of CTV over multi-sig? > >>___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Swift Activation - CTV
Hey AJ Thanks for this, pretty much agree with all of it. It seems like a week doesn't go by now without a new individual popping out the woodwork proposing an upcoming activation of CTV with no new PoCs and no new insights. I'm not sure what it is about CTV (versus say other proposals) that it keeps attracting these people that refuse to work on PoCs or anything that drives the research area forward and yet want to try to attempt activation where the success scenario would be a chain split. > > But "target fixation" [0] is a thing too: maybe "CTV" (and/or "APO") were > > just a bad approach from the start. It is hard to discuss APO in a vacuum when this is going on the background but I'm interested in you grouping APO with CTV in this statement. At the time of writing there clearly isn't consensus or advanced PoCs on any of the use cases CTV claims to enable. (One rare exception on the use case front is James O'Beirne's OP_VAULT [0] that requires additional opcodes to OP_CTV). But APO does seem to be the optimal design and have broad consensus in the Lightning community for enabling eltoo/LN-Symmetry. Any other use cases APO enables would be an additional benefit. I don't think one can seriously think about an *upcoming* activation for APO as there is still more work to do to convince the community that it would be worth the risks of embarking on another activation process. But assuming another year of concerted work on APO and the CTV woodwork of chaos (hopefully) being exhausted do you think an APO activation would be viable in say 2025/2026? Is your hesitancy on APO based on any particular technical concerns or just fatigue from the CTV chaos? Thanks Michael [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Saturday, 30 December 2023 at 08:05, Anthony Towns via bitcoin-dev wrote: > Huh, this list is still active? > > On Fri, Dec 22, 2023 at 10:34:52PM +, alicexbt via bitcoin-dev wrote: > > > I think CTV is not ready for activation yet. Although I want it to be > > activated and use payment pools, we still have some work to do and AJ is > > correct that we need to build more apps that use CTV on signet. > > > I've said it before, and I'll say it again, but if you want to change > bitcoin consensus rules, IMO the sensible process is: > > * work out what you think the change should be > * demonstrate the benefits so everyone can clearly see what they are, > and that they're worth spending time on > * review the risks, so that whatever risks there may be are well > understood, and minimise them > * iterate on all three of those steps to increase the benefits and > reduce the risks > * once "everyone" agrees the benefits are huge and the risks are low, > work on activating it > > If you're having trouble demonstrating that the benefits really are > worth spending time on, you probably need to go back to the first step > and reconsider the proposal. The "covtools" and "op_cat" approaches are > a modest way of doing that: adding additional opcodes that mesh well > with CTV, increasing the benefits from making a change. > > But "target fixation" [0] is a thing too: maybe "CTV" (and/or "APO") > were just a bad approach from the start. Presumably "activate CTV" > is really intended as a step towards your actual goal, whether that be > "make it harder for totalitarians to censor payments", "replace credit > cards", "make lots of money", "take control over bitcoind evelopment", > or something else. Maybe there's a better step towards some/all of > whatever those goals may be than "activate CTV". Things like "txhash" > take that approach and go back to the first step. > > To me, it seems like CTV has taken the odd approach of simultaneously > maximising (at least perceived) risk, while minimising the potential > benefits. As far as maximising risk goes, it's taken Greg Maxwell's > "amusingly bad idea" post from bitcointalk in 2013 [1] and made the bad > consequence described there (namely, "coin covenants", which left Greg > "screaming in horror") as the centrepiece of the functionality being > added, per its motivation section. It then minimises the potential > benefits that accompany that risk by restricting the functionality being > provided as far as you can without neutering it entirely. If you wanted > a recipe for how to propose a change to bitcoin and ensure that it's > doomed to fail while still gathering a lot of attention, I'm honestly > not sure how you could come up with a better approach? > > [0] https://en.wikipedia.org/wiki/Target_fixation > [1] https://bitcointalk.org/index.php?topic=278122.0 > > > - Apart from a few PoCs that do not achieve anything big on mainnet, nobody > > has tried to build PoC for a use case that solves real problems > > >
Re: [bitcoin-dev] Responsible disclosures and Bitcoin development
Hi alicexbt > It has been assigned CVE-2023-33297 Did you personally request the CVE ID? Say via here [0]? Did you confirm with someone listed on the vulnerability reporting process [1] for Bitcoin Core that it made sense to do that at this time? I'm not sure whether completely bypassing that list and requesting CVE IDs for the project as an individual is the way to go. If you have already contacted one of them and they've given you the go ahead to start the CVE process then fine. You weren't particularly clear with what has occurred. Thanks Michael [0]: https://cve.mitre.org/cve/request_id.html [1]: https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Monday, May 22nd, 2023 at 13:56, alicexbt wrote: > Hi Michael, > > > Now that's not to say you may not have a point about better documentation > > and guidance on what should go through the vulnerability reporting process > > and what shouldn't. > > > Yes, this can be improved. > > > Or even that this particular issue could ultimately end up being classed a > > CVE. > > > It has been assigned CVE-2023-33297 > > > /dev/fd0 > floppy disk guy > > Sent with Proton Mail secure email. > > --- Original Message --- > On Wednesday, May 17th, 2023 at 6:14 PM, Michael Folkson > michaelfolk...@protonmail.com wrote: > > > > > Hi alicexbt > > > > "Open source" has the word "open" in it. Pushing everything into closed, > > private channels of communication and select groups of individuals is what > > I've been trying to push back upon. As I said in my initial response "it > > doesn't scale for all bug reports and investigations to go through this > > tiny funnel" though "there are clearly examples where the process is > > critically needed". > > > > Now that's not to say you may not have a point about better documentation > > and guidance on what should go through the vulnerability reporting process > > and what shouldn't. Or even that this particular issue could ultimately end > > up being classed a CVE. But rather than merely complaining and putting > > "open source" into quote marks perhaps suggest what class of bug reports > > should go through the tiny funnel and what shouldn't. Unless you think > > everything should go through the funnel in which case you are advocating > > for less openness whilst simultaneously complaining it isn't "open source". > > Square that circle. > > > > Thanks > > Michael > > > > -- > > Michael Folkson > > Email: michaelfolkson at protonmail.com > > GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F > > > > Learn about Bitcoin: https://www.youtube.com/@portofbitcoin > > > > --- Original Message --- > > On Tuesday, May 16th, 2023 at 23:39, alicexbt alice...@protonmail.com wrote: > > > > > Hi Michael, > > > > > > A disagreement and some thoughts already shared in an email although its > > > not clear to some "open source" devs: > > > > > > Impact of this vulnerability: > > > > > > - Denial of Service > > > - Stale blocks affecting mining pool revenue > > > > > > Why it should have been reported privately to secur...@bitcoincore.org, > > > even if initially found affecting only debug build? > > > > > > Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3129 > > > > > > CVE is a different process and I am aware of it. It would be good for > > > certain developers in the core team to reflect on their own approach to > > > security, regardless of whether their work receives CVE recognition or > > > not. > > > > > > /dev/fd0 > > > floppy disk guy > > > > > > Sent with Proton Mail secure email. > > > > > > --- Original Message --- > > > On Friday, May 12th, 2023 at 1:14 AM, Michael Folkson > > > michaelfolk...@protonmail.com wrote: > > > > > > > Hi alicexbt > > > > > > > > The vulnerability reporting process requires communication and > > > > resolution via a small group of individuals 0 rather than through open > > > > collaboration between any contributors on the repo. There are clearly > > > > examples where the process is critically needed, the most obvious past > > > > example being the 2018 inflation bug 1. However, it doesn't scale for > > > > all bug reports and investigations to go through this tiny funnel. For > > > > an issue that isn't going to result in loss of onchain funds and > > > > doesn't seem to present a systemic issue (e.g. network DoS attack, > > > > inflation bug) I'm of the view that opening a public issue was > > > > appropriate in this case especially as the issue initially assumed it > > > > was only impacting nodes running in debug mode (not a mode a node in > > > > production is likely to be running in). > > > > > > > > An interesting question though and I'm certainly happy to be corrected > > > > by
Re: [bitcoin-dev] Responsible disclosures and Bitcoin development
Hi alicexbt "Open source" has the word "open" in it. Pushing everything into closed, private channels of communication and select groups of individuals is what I've been trying to push back upon. As I said in my initial response "it doesn't scale for all bug reports and investigations to go through this tiny funnel" though "there are clearly examples where the process is critically needed". Now that's not to say you may not have a point about better documentation and guidance on what should go through the vulnerability reporting process and what shouldn't. Or even that this particular issue could ultimately end up being classed a CVE. But rather than merely complaining and putting "open source" into quote marks perhaps suggest what class of bug reports should go through the tiny funnel and what shouldn't. Unless you think everything should go through the funnel in which case you are advocating for less openness whilst simultaneously complaining it isn't "open source". Square that circle. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Tuesday, May 16th, 2023 at 23:39, alicexbt wrote: > Hi Michael, > > A disagreement and some thoughts already shared in an email although its not > clear to some "open source" devs: > > Impact of this vulnerability: > > - Denial of Service > - Stale blocks affecting mining pool revenue > Why it should have been reported privately to secur...@bitcoincore.org, even > if initially found affecting only debug build? > > Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3129 > > CVE is a different process and I am aware of it. It would be good for certain > developers in the core team to reflect on their own approach to security, > regardless of whether their work receives CVE recognition or not. > > /dev/fd0 > floppy disk guy > > Sent with [Proton Mail](https://proton.me/) secure email. > > --- Original Message --- > On Friday, May 12th, 2023 at 1:14 AM, Michael Folkson > wrote: > >> Hi alicexbt >> >> The vulnerability reporting process requires communication and resolution >> via a small group of individuals [0] rather than through open collaboration >> between any contributors on the repo. There are clearly examples where the >> process is critically needed, the most obvious past example being the 2018 >> inflation bug [1]. However, it doesn't scale for all bug reports and >> investigations to go through this tiny funnel. For an issue that isn't going >> to result in loss of onchain funds and doesn't seem to present a systemic >> issue (e.g. network DoS attack, inflation bug) I'm of the view that opening >> a public issue was appropriate in this case especially as the issue >> initially assumed it was only impacting nodes running in debug mode (not a >> mode a node in production is likely to be running in). >> >> An interesting question though and I'm certainly happy to be corrected by >> those who have been investigating the issue. Some delicate trade-offs >> involved including understanding and resolving the issue faster through >> wider collaboration versus keeping knowledge of the issue within a smaller >> group. >> >> Thanks >> Michael >> >> [0]: https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md >> [1]: https://bitcoincore.org/en/2018/09/20/notice/ >> >> -- >> Michael Folkson >> Email: michaelfolkson at [protonmail.com](http://protonmail.com/) >> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F >> >> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin >> >> --- Original Message --- >> On Tuesday, May 9th, 2023 at 03:47, alicexbt via bitcoin-dev >> wrote: >> >>> Hi Bitcoin Developers, >>> >>> There is an open issue in bitcoin core repository which was created last >>> week: https://github.com/bitcoin/bitcoin/issues/27586 >>> >>> I think this should have been reported privately as vulnerability instead >>> of creating a GitHub issue even if it worked only in debug mode. Some users >>> in the comments have also experienced similar issues without debug build >>> used for bitcoind. I have not noticed any decline in the number of >>> listening nodes on bitnodes.io in last 24 hours so I am assuming this is >>> not an issue with majority of bitcoin core nodes. However, things could >>> have been worse and there is nothing wrong in reporting something privately >>> if there is even 1% possibility of it being a vulnerability. I had recently >>> reported something to LND security team based on a closed issue on GitHub >>> which eventually was not considered a vulnerability: >>> https://github.com/lightningnetwork/lnd/issues/7449 >>> >>> In the CPU usage issue, maybe the users can run bitcoind with bigger >>> mempool or try other things shared in the issue by everyone. >>> >>> This isn't the first ti
Re: [bitcoin-dev] Responsible disclosures and Bitcoin development
Hi alicexbt The vulnerability reporting process requires communication and resolution via a small group of individuals [0] rather than through open collaboration between any contributors on the repo. There are clearly examples where the process is critically needed, the most obvious past example being the 2018 inflation bug [1]. However, it doesn't scale for all bug reports and investigations to go through this tiny funnel. For an issue that isn't going to result in loss of onchain funds and doesn't seem to present a systemic issue (e.g. network DoS attack, inflation bug) I'm of the view that opening a public issue was appropriate in this case especially as the issue initially assumed it was only impacting nodes running in debug mode (not a mode a node in production is likely to be running in). An interesting question though and I'm certainly happy to be corrected by those who have been investigating the issue. Some delicate trade-offs involved including understanding and resolving the issue faster through wider collaboration versus keeping knowledge of the issue within a smaller group. Thanks Michael [0]: https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md [1]: https://bitcoincore.org/en/2018/09/20/notice/ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Tuesday, May 9th, 2023 at 03:47, alicexbt via bitcoin-dev wrote: > Hi Bitcoin Developers, > > There is an open issue in bitcoin core repository which was created last > week: https://github.com/bitcoin/bitcoin/issues/27586 > > I think this should have been reported privately as vulnerability instead of > creating a GitHub issue even if it worked only in debug mode. Some users in > the comments have also experienced similar issues without debug build used > for bitcoind. I have not noticed any decline in the number of listening nodes > on bitnodes.io in last 24 hours so I am assuming this is not an issue with > majority of bitcoin core nodes. However, things could have been worse and > there is nothing wrong in reporting something privately if there is even 1% > possibility of it being a vulnerability. I had recently reported something to > LND security team based on a closed issue on GitHub which eventually was not > considered a vulnerability: > https://github.com/lightningnetwork/lnd/issues/7449 > > In the CPU usage issue, maybe the users can run bitcoind with bigger mempool > or try other things shared in the issue by everyone. > > This isn't the first time either when vulnerability was reported publicly: > https://gist.github.com/chjj/4ff628f3a0d42823a90edf47340f0db9 and this was > even exploited on mainnet which affected some projects. > > This email is just a request to consider the impact of any vulnerability if > gets exploited could affect lot of things. Even the projects with no > financial activity involved follow better practices. > > /dev/fd0 > floppy disk guy > > Sent with [Proton Mail](https://proton.me/) secure email.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
Thanks for this Andrew. > However I later spoke to a few others privately who were more familiar with > Vasil's work and they had told me that they were not comfortable with Vasil > being P2P maintainer. Some individuals who will stay anonymous and who were more familiar with Vasil's work than you weren't happy with the standard of his work. Ok I hope they have communicated this to him directly and provided specific examples where he can improve. > From having received plenty of reviews from ryanofsky, I can certainly say > that his reviews are in depth. He has pointed out subtle bugs, asks questions > about very low level details, and has well reasoned critiques and discussions > about design decisions. And Vasil didn't provide as in depth reviews when compared to ryanofsky. Again I hope they have communicated this to him directly. > Many cited your behavior as a primary reason to stop discussing things > publicly, with things such as dragging project meta discussions onto the > mailing list and twitter. These have invited abuse towards maintainers and > contributors, which in turn makes them takes those discussions to more > private settings. People feel like they're getting sealioned by you (and a > few others) when they post publicly, and so they have stopped doing so. I have tried over and over again on IRC and on GitHub and I've been ignored. To claim discussions on the bitcoin-dev mailing list invite abuse is just laughable. It is public just like IRC logs and GitHub. If people don't like discussing in public we should give up the pretense and put on the Core README that all important discussions on decision making are done in private and are invite only. > People feel like they're getting sealioned by you (and a few others) when > they post publicly, and so they have stopped doing so. This is the "rude" and "aggressive" accusation, right. Someone asks questions that maintainers don't want to answer, maintainers accuse them of being "rude" and "aggressive" and then use that as a justification for not answering those questions in the first place. It is a pretty effective strategy. Don't even need to provide examples, just label them and then you can ignore them. > Since you are intent on discussing and re-litigating the decision about > Vasil, I will agree that we (the maintainers) could have done a better job of > communicating. However we stand by the decision that was made in the end, and > we did have a chat with him about it during CoreDev. Thanks for at least admitting this on the communication point. If Vasil has been spoken to and is happy with the situation then the situation is much better than I feared. You might think this is re-litigating but the addition, rejection and removal of maintainers is among the most important decisions you can make as a maintainer and perhaps only dwarfed by the merging of consensus changes that can cause chain splits. If anything should be "re-litigated" it should be this. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Wednesday, May 10th, 2023 at 22:24, Andrew Chow via bitcoin-dev wrote: > On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote: > >> The decision process for adding a new maintainer was according to the IRC >> meeting that the maintainers decided privately there was a need for a >> maintainer “who understood our interfaces and modularization efforts well” >> and that ryanofsky was a “good fit for that”. I don’t know whether this was >> decided in a private IRC channel or was decided at the recent in person Core >> Dev meeting. Regardless, many have had no input into the discussion on what >> kind of maintainer the project needs going forward and it seems the >> maintainers do not want to discuss that aspect of the decision. > > Since the project began, the decision to seek out and then add a maintainer > has always been made by existing maintainers. When the maintainers feel that > there is a need for additional maintainers, they may have an open call for > volunteers, or may have a candidate already in mind and suggest that specific > person for maintainership. Contributors generally are not consulted in the > decision to seek a new maintainer as they would not know whether there are > things that are being overlooked or that there is maintainership load that > needs to be distributed. Even so, it wouldn't be appropriate to add a > maintainer if many contributors disagreed with it, just as with any other PR. > > We can take a lo
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
> Blocking Vasil was discussed on a similar GitHub PR. Whether or not one > agrees or disagrees, the same process is being used. Anyone can NACK and give > a reason for Russ as well. With respect Steve the process for Vasil was keeping Vasil's PR open for up to 5 months with zero NACKs and two maintainers refusing to engage on why it wasn't being merged or what it needed for it to be merged. Followed by a later justification for blocking it that they've refused to discuss whether it applies to Russ. The process for Russ was the maintainers deciding privately there was a need for a maintainer "who understood our interfaces and modularization efforts well" and his PR was merged within 2 days. If that's the same process to you I don't know what to say. We have different perspectives on what constitutes a decision process. (I'm sure this is clear but just to reiterate in case it isn't none of this is a criticism of Russ.) Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Wednesday, May 10th, 2023 at 17:36, Steve Lee wrote: > Blocking Vasil was discussed on a similar GitHub PR. Whether or not one > agrees or disagrees, the same process is being used. Anyone can NACK and give > a reason for Russ as well. > > On Wed, May 10, 2023 at 8:55 AM Michael Folkson > wrote: > >> Hi Steve >> >>> Isn't this as simple as anyone (in particular Core project contributors) >>> can express their view in this >>> PR?https://github.com/bitcoin/bitcoin/pull/27604 >> >> Nope. The extent to which the rationale for blocking Vasil as a maintainer >> applies or doesn't apply to ryanofsky (or future potential maintainers) >> isn't discussed. From now on the precedent is proposed maintainers can be >> blocked for unknown and/or potentially inconsistent reasons by the existing >> maintainers. >> >> Thanks >> Michael >> >> -- >> Michael Folkson >> Email: michaelfolkson at [protonmail.com](http://protonmail.com/) >> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F >> >> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin >> >> --- Original Message --- >> On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev >> wrote: >> >>> Isn't this as simple as anyone (in particular Core project contributors) >>> can express their view in this PR? >>> https://github.com/bitcoin/bitcoin/pull/27604 >>> >>> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev >>> wrote: >>> >>>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev >>>> wrote: >>>> >>>>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote: >>>>>> Essentially my concern is going forward current maintainers will >>>>>> decide which proposed new maintainers to add and which to block. >>>>> >>>>> This is how a large percentage of organizations are run. The current >>>>> members of a board or other governance group choose who will become a >>>>> new board member. >>>> >>>> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of >>>> independent contributors merging different pull requests or patches. The >>>> github controls are merely because that is how github works. There is also >>>> a secondary issue of people tending to confuse Bitcoin Core with the >>>> bitcoin protocol in general: >>>> https://blog.lopp.net/who-controls-bitcoin-core/ >>>> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd >>>> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427 >>>> >>>> - Bryan >>>> https://twitter.com/kanzure >>>> ___ >>>> 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] Bitcoin Core maintainers and communication on merge decisions
Hi Steve > Isn't this as simple as anyone (in particular Core project contributors) can > express their view in this PR?https://github.com/bitcoin/bitcoin/pull/27604 Nope. The extent to which the rationale for blocking Vasil as a maintainer applies or doesn't apply to ryanofsky (or future potential maintainers) isn't discussed. From now on the precedent is proposed maintainers can be blocked for unknown and/or potentially inconsistent reasons by the existing maintainers. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev wrote: > Isn't this as simple as anyone (in particular Core project contributors) can > express their view in this PR? https://github.com/bitcoin/bitcoin/pull/27604 > > On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev > wrote: > >> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev >> wrote: >> >>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote: >>>> Essentially my concern is going forward current maintainers will >>>> decide which proposed new maintainers to add and which to block. >>> >>> This is how a large percentage of organizations are run. The current >>> members of a board or other governance group choose who will become a >>> new board member. >> >> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of >> independent contributors merging different pull requests or patches. The >> github controls are merely because that is how github works. There is also a >> secondary issue of people tending to confuse Bitcoin Core with the bitcoin >> protocol in general: >> https://blog.lopp.net/who-controls-bitcoin-core/ >> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd >> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427 >> >> - Bryan >> https://twitter.com/kanzure >> ___ >> 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] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
> im unclear as to the purposepaying an onchain transaction fee greater than
> the amount receiving could possibly serve.
If you expect fees to continue to rise and be sustained at abnormally high
levels for a long period of time you might seek to close your Lightning
channel(s) and move whatever value you can from these Lightning channel(s)
onchain even if it means paying a higher fee than the amount you are receiving.
I don't necessarily recommend doing this (it would depend on a number of
factors, both personal and external) but there is no reason to prevent someone
in say the consensus rules from doing this if they wish.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
--- Original Message ---
On Monday, May 8th, 2023 at 20:47, Erik Aronesty wrote:
> im unclear as to the purpose paying an onchain transaction fee greater than
> the amount receiving could possibly serve.
>
> what benefit do you get aside from losing bitcoin?
>
> are there any, non-theoretical, benefits to facilitating dust transactions?
>
> we could, of course, have it be non-consensus (no route dust) to start with
>
> On Mon, May 8, 2023 at 1:13 PM Michael Folkson
> wrote:
>
>>> probably easier just to reject any transaction where the fee is higher than
>>> the sum of the outputs
>>
>> And prevent perfectly reasonable transfers of value and attempted Lightning
>> channel closes during fee spikes? If I want to close my Lightning channel
>> during a protracted fee spike where I have to pay an onchain transaction fee
>> greater than the amount I am receiving you want to stop me doing that? You
>> are impinging on a valid use case as well as requiring a consensus rule
>> change.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> --- Original Message ---
>> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev
>> wrote:
>>
>>> probably easier just to reject any transaction where the fee is higher than
>>> the sum of the outputs
>>>
>>> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev
>>> wrote:
>>>
Hi guys,
I think everyone on this list knows what has happened to the Bitcoin
mempool during the past 96 hours. Due to side projects such as BRC-20
having such a high volume, real bitcoin transactions are being priced out
and that is what is causing the massive congestion that has arguable not
been seen since December 2017. I do not count the March 2021 congestion
because that was only with 1-5sat/vbyte.
Such justifiably worthless ("worthless" is not even my word - that's how
its creator described them[1]) tokens threaten the smooth and normal use
of the Bitcoin network as a peer-to-pear digital currency, as it was
intended to be used as.
If the volume does not die down over the next few weeks, should we take an
action? The bitcoin network is a triumvirate of developers, miners, and
users. Considering that miners are largely the entities at fault for
allowing the system to be abused like this, the harmony of Bitcoin
transactions is being disrupted right now. Although this community has a
strong history of not putting its fingers into pies unless absolutely
necessary - an example being during the block size wars and Segwit -
should similar action be taken now, in the form of i) BIPs and/or ii)
commits into the Bitcoin Core codebase, to curtail the loophole in BIP 342
(which defines the validation rules for Taproot scripts) which has allowed
these unintended consequences?
An alternative would be to enforce this "censorship" at the node level and
introduce a run-time option to instantly prune all non-standard Taproot
transactions. This will be easier to implement, but won't hit the road
until minimum next release.
I know that some people will have their criticisms about this,
absolutists/libertarians/maximum-freedom advocates, which is fine, but we
need to find a solution for this that fits everyone's common ground. We
indirectly allowed this to happen, which previously wasn't possible
before. So we also have a responsibility to do something to ensure that
this kind of congestion can never happen again using Taproot.
-Ali
---
[1]:
[https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/](https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp)
___
bit
Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
> probably easier just to reject any transaction where the fee is higher than
> the sum of the outputs
And prevent perfectly reasonable transfers of value and attempted Lightning
channel closes during fee spikes? If I want to close my Lightning channel
during a protracted fee spike where I have to pay an onchain transaction fee
greater than the amount I am receiving you want to stop me doing that? You are
impinging on a valid use case as well as requiring a consensus rule change.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
--- Original Message ---
On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev
wrote:
> probably easier just to reject any transaction where the fee is higher than
> the sum of the outputs
>
> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev
> wrote:
>
>> Hi guys,
>>
>> I think everyone on this list knows what has happened to the Bitcoin mempool
>> during the past 96 hours. Due to side projects such as BRC-20 having such a
>> high volume, real bitcoin transactions are being priced out and that is what
>> is causing the massive congestion that has arguable not been seen since
>> December 2017. I do not count the March 2021 congestion because that was
>> only with 1-5sat/vbyte.
>>
>> Such justifiably worthless ("worthless" is not even my word - that's how its
>> creator described them[1]) tokens threaten the smooth and normal use of the
>> Bitcoin network as a peer-to-pear digital currency, as it was intended to be
>> used as.
>>
>> If the volume does not die down over the next few weeks, should we take an
>> action? The bitcoin network is a triumvirate of developers, miners, and
>> users. Considering that miners are largely the entities at fault for
>> allowing the system to be abused like this, the harmony of Bitcoin
>> transactions is being disrupted right now. Although this community has a
>> strong history of not putting its fingers into pies unless absolutely
>> necessary - an example being during the block size wars and Segwit - should
>> similar action be taken now, in the form of i) BIPs and/or ii) commits into
>> the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which defines
>> the validation rules for Taproot scripts) which has allowed these unintended
>> consequences?
>>
>> An alternative would be to enforce this "censorship" at the node level and
>> introduce a run-time option to instantly prune all non-standard Taproot
>> transactions. This will be easier to implement, but won't hit the road until
>> minimum next release.
>>
>> I know that some people will have their criticisms about this,
>> absolutists/libertarians/maximum-freedom advocates, which is fine, but we
>> need to find a solution for this that fits everyone's common ground. We
>> indirectly allowed this to happen, which previously wasn't possible before.
>> So we also have a responsibility to do something to ensure that this kind of
>> congestion can never happen again using Taproot.
>>
>> -Ali
>>
>> ---
>>
>> [1]:
>> [https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/](https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp)
>>
>> ___
>> 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] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
Hi Ali I'd point you to Andrew Poelstra's post from January 2023 [0] and a Bitcoin StackExchange answer I recently posted [1]. > Considering that miners are largely the entities at fault for allowing the > system to be abused like this, the harmony of Bitcoin transactions is being > disrupted right now. Miners are as far as I understand including high fee rate, consensus compatible transactions in mined blocks as the system has been set up for them to do. As I say in that StackExchange answer if you don't like it: "There are theoretically two options: a consensus change or a policy change. A consensus change disallowing a certain kind of transaction that is acceptable under current consensus rules would need a soft fork and hence would be extremely difficult to pull off assuming that it was a considered a good idea by the broader community. Embedding arbitrary data in transactions would still be possible after this hypothetical soft fork and so its effectiveness would be limited. A default policy change (or custom policy option) would attempt to prevent a certain kind of transaction from propagating across the network without needing a consensus change. However, it would still be possible to submit these kinds of consensus compatible transactions directly to miners bypassing the P2P network." > I know that some people will have their criticisms about this, > absolutists/libertarians/maximum-freedom advocates, which is fine, but we > need to find a solution for this that fits everyone's common ground. We > indirectly allowed this to happen, which previously wasn't possible before. > So we also have a responsibility to do something to ensure that this kind of > congestion can never happen again using Taproot. It isn't a philosophy or ideology consideration, it is a purely technical one. Congestion can happen using Taproot addresses or pre-Taproot addresses. There is fixed, limited block space and variable demand for that block space. You may not like how that block space is being used but if transactions are consensus compatible and paying fees at the market rate the system is working how it should. > to curtail the loophole in BIP 342 (which defines the validation rules for > Taproot scripts) which has allowed these unintended consequences? There were technical reasons for the design decisions in BIP 342. As Andrew says in his post [0]: "If we ban "useless data" then it would be easy for would-be data storers to instead embed their data inside "useful" data such as dummy signatures or public keys. Doing so would incur a ~2x cost to them, but if 2x is enough to disincentivize storage, then there's no need to have this discussion because they will will be forced to stop due to fee market competition anyway. (And if not, it means there is little demand for Bitcoin blockspace, so what's the problem with paying miners to fill it with data that validators don't even need to perform real computation on?). But if we were to ban "useful" data, for example, saying that a witness can't have more than 20 signatures in it, then we are into the same problem we had pre-Taproot: that it is effectively impossible construct signing policies in a general and composeable way, because any software that does so will need to account for multiple independent limits. We deliberately replaced such limits with "you need to pay 50 weight for each signature" to makes this sort of analysis tractable." I personally get the desire to "do something". Fee spikes aren't fun especially for some Lightning use cases and many of us don't like how people are using the limited block space currently. But a game of whack-a-mole with blunt tools such as policy rules and especially consensus rules is ineffective at best and harmful at worst. You may not like this use case but assuming you embark on a game of whack-a-mole what's to stop a group of people popping up in a year declaring their opposition to your use case and trying to prevent your use case? Consensus rules are set and the rest is left to the market. Thanks Michael [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021372.html [1]: https://bitcoin.stackexchange.com/questions/118197/ddos-attack-via-brc-20-ordinals-on-bitcoin -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Sunday, May 7th, 2023 at 18:22, Ali Sherief via bitcoin-dev wrote: > Hi guys, > > I think everyone on this list knows what has happened to the Bitcoin mempool > during the past 96 hours. Due to side projects such as BRC-20 having such a > high volume, real bitcoin transactions are being priced out and that is what > is causing the massive congestion that has arguable not been seen since > December 2017. I do not count the March 2021 congestion because that was only
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
Hi David
>> Essentially my concern is going forward current maintainers will decide
>> which proposed new maintainers to add and which to block.
> This is how a large percentage of organizations are run. The current members
> of a board or other governance group choose who will become a new board
> member.
So long term contributors who aren't maintainers don't get input into the
decision? It is starting to seem like the maintainer role is moving from a
janitorial one to where maintainers make decisions without discussing those
decisions with long term contributors and in some cases even bothering to
explain the rationale for those decisions to a broader audience that includes
long term contributors. This unfortunately makes the decision on who becomes a
maintainer even more important.
Decisions have to be made but I was always under the impression that they would
be discussed in open, public IRC meetings with at least other long term
contributors present and then decisions would be made based on the views
expressed in that meeting. An appointed board or governance group ("the
maintainers") wasn't how I thought the project was run or should be run.
> Finally, I don't think this matter warranted a post to this mailing list.
> Discussion about internal project decisions, such as who should have merge
> access and what maintainers should communicate in PRs, belong in
> communication channels dedicated to that project.
I have tried. As I said in previous emails in the Vasil maintainer case I asked
fanquake, Gloria repeatedly over a period of 5 months why Vasil was being
blocked. They refused to comment. I get called "rude" and "aggressive" for
asking. So I'd rather post my thoughts and observations here than risk being
accused of being "rude" and "aggressive" again for asking questions on this
topic on IRC. Especially as I expect they'll be ignored anyway as they were in
last week's Core Dev IRC meeting.
Until the Vasil situation I thought that we had a common sense approach of any
long term contributor who had demonstrated they could add value to the project
and had shown good temperament could become a maintainer. Blocking Vasil as a
maintainer was a red flag for me that we no longer have that. And fanquake,
Gloria not being willing to discuss why publicly for 5 months was a second red
flag. If that is the precedent for merge decisions anything is possible in the
future including in the worst case contentious consensus change merges with no
justification and no rationale.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
--- Original Message -------
On Sunday, May 7th, 2023 at 18:35, David A. Harding wrote:
> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>
> > Essentially my concern is going forward current maintainers will
> > decide which proposed new maintainers to add and which to block.
>
>
> This is how a large percentage of organizations are run. The current
> members of a board or other governance group choose who will become a
> new board member.
>
> One alternative to self-perpetuating governance is membership voting,
> but building and maintaining democratic institutions is hard and not a
> good fit for many types of endeavors---the building of highly technical
> software being one of those cases IMO.
>
> I think the questions we want to ask is whether the current set of
> maintainers is capable of moving Bitcoin Core in the direction we want
> and what we can do about it if we conclude that they are ill-suited (or
> malicious). For the first question, I think that's something everyone
> needs to answer for themselves, as we may each have different visions
> for the future of the project. That said, I note that several
> initiatives championed by the current maintainers in the IRC meeting you
> mention received overwhelmingly positive support from a significant
> number of current contributors, which seems like a healthy sign to me.
>
> For the second question, I think AJ Towns already answered that quite
> well (though he was talking about a different project):
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021578.html
>
> Finally, I don't think this matter warranted a post to this mailing
> list. Discussion about internal project decisions, such as who should
> have merge access and what maintainers should communicate in PRs, belong
> in communication channels dedicated to that project.
>
> -Dave
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
There has been a proposed new maintainer on Bitcoin Core (ryanofsky). In the Core dev IRC meeting [0] yesterday it received multiple ACKs. The decision process for adding a new maintainer was according to the IRC meeting that the maintainers decided privately there was a need for a maintainer “who understood our interfaces and modularization efforts well” and that ryanofsky was a “good fit for that”. I don’t know whether this was decided in a private IRC channel or was decided at the recent in person Core Dev meeting. Regardless, many have had no input into the discussion on what kind of maintainer the project needs going forward and it seems the maintainers do not want to discuss that aspect of the decision. I posted a couple of questions in advance [1] of the meeting (I was unable to attend) that remained unanswered during the meeting. Essentially my concern is going forward current maintainers will decide which proposed new maintainers to add and which to block. If you aren’t anointed by the current maintainers you won’t get added as a maintainer and a half baked rationale will be provided to justify that decision. Longer term this will determine the pull requests that will ultimately get merged and which don't get merged because maintainers merge pull requests. One of the justifications for blocking Vasil Dimov as a new maintainer despite many initial ACKs from maintainers (including Andrew Chow) and long term contributors was according to Andrew [2]: “Maintainers inherently need to look at the things that everyone else has already looked at, if only to give it a final once over before merging (but hopefully, an actual review, not just looking it over).” I follow the Bitcoin Core repo pretty closely and I haven’t seen ryanofsky do this any more than Vasil does. This is not a criticism of ryanofsky, just as I wouldn’t use it as a criticism for Vasil. It would get pretty annoying if everyone who wasn’t a maintainer posted an ACK once many long term contributors had already ACKed to display supposed “desired maintainer traits”. Especially if you are essentially just ACKing that others have done the work to review the PR and you just want to get your ACK on it to increase your ACK count without doing a fraction of what previous reviewers have done. “I also want to mention that the people who have become maintainers in the past have had this kind of maintainer attitude towards review prior to becoming a maintainer” Assuming ryanofsky hasn’t had this maintainer attitude in the past (again not a criticism from me at least) does this mean this was a reason to block Vasil but not a reason to block ryanofsky? That seems inconsistent to me. When you’re anointed you don’t need to meet requirements but when you’re blocked these requirements will be used to block your addition as a new maintainer? For what it is worth from a personal perspective I don’t see any reason for blocking ryanofsky as a maintainer especially if there is broad agreement amongst maintainers and long term contributors that we need a new maintainer who understands interfaces and modularization on the project. For that framing ryanofsky perfectly meets those requirements. But once again the (public) discussion element on the addition of maintainers is essentially a façade, a framing for what the new maintainer needs to be has been decided in advance (in private) and an anointed individual who just so happens to align with that convenient framing will get added as a new maintainer. On a more positive note there does seem to be more energy and momentum for collaboration and open communication on the project since I discussed communication in a previous post [3]. Hopefully this will continue. It doesn’t address my concerns on maintainers and ultimately merge decisions but it definitely seems to me to be a step in a positive direction for the project. [0]: https://gnusha.org/bitcoin-core-dev/2023-05-04.log [1]: https://gnusha.org/bitcoin-core-dev/2023-05-01.log [2]: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1382334059 [3]:https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021565.html -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Tuesday, April 18th, 2023 at 13:40, Michael Folkson wrote: > Communication has been a challenge on Bitcoin Core for what I can tell the > entire history of the project. Maintainers merge a pull request and provide > no commentary on why they’ve merged it. Maintainers leave a pull request with > many ACKs and few (if any) NACKs for months and provide no commentary on why > they haven't merged it. I can only speculate on why and it probably depends > on the individual maintainer. Sometimes it will be poor communication skills, > sometimes it will be
Re: [bitcoin-dev] Vaults in the MATT framework
Hi Salvatore
Can you clarify for me which bucket this proposal sits? We have APO, CTV,
OP_VAULT etc that are proposals to add additional functionality to SegWit
version 1, Tapleaf version 0 scripts. We have Simplicity that would need a new
Tapleaf version (e.g. Tapleaf version 1). And then there are CISA like
proposals that would need a new SegWit version (e.g. SegWit version 2). It
looks to me like your proposal is in the first bucket (same as APO, CTV etc) as
it is just introducing new opcode functionality to existing script with no
deeper introspection needed but previous and current discussion of fraud
proofs, MATT frameworks etc made me initially think it was going to require
more than that.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
--- Original Message ---
On Monday, April 24th, 2023 at 20:37, Salvatore Ingala via bitcoin-dev
wrote:
> Hello list,
>
> TL;DR: the core opcodes of MATT can build vaults with a very similar design
> to OP_VAULT. Code example here:
>
> https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...bigspider:bitcoin-inquisition:matt-vault
>
> In my previous emails about the MATT proposal for smart contracts in
> bitcoin [1], I mostly focused on proving its generality; that is, it
> allows arbitrary smart contracts thanks to fraud proofs.
>
> While I still find this "completeness" result compelling, I spent more time
> thinking about the framework itself; the construction is not very interesting
> if it turns simple things into complicated ones. Luckily, this is not the
> case.
> In particular, in this email we will not merkleize anything (other than
> taptrees).
>
> This post describes some progress into formalizing the semantics of the core
> opcodes, and demonstrates how they could be used to create vaults that seem
> comparable to the ones built with OP_VAULT [2], despite using general purpose
> opcodes.
>
> An implementation and some minimal tests matching the content of this
> e-mail can be found in the link above, using the bitcoin-inquisition as the
> base branch.
>
> Note that the linked code is not well tested and is only intended for
> exploratory and demonstrative purposes; therefore, bugs are likely at this
> stage.
>
> ##
> # PART 1: MATT's core
> ##
>
> In this section, I will discuss plausible semantics for the core opcodes for
> MATT.
>
> The two core opcodes are defined below as OP_CHECKINPUTCONTRACTVERIFY and
> OP_CHECKOUTPUTCONTRACTVERIFY.
>
> (the initial posts named them OP_CHECK{INPUT,OUTPUT}COVENANTVERIFY)
>
> They enhance Script with the following capabilities:
> - decide the taptree of the output
> - embed some (dynamically computed) data in the output
> - access the embedded data in the current UTXO (if any)
>
> The opcodes below are incomplete, as they only control the output's Script and
> not the amounts; more on that below.
>
> Other than that, the semantics should be quite close to the "right" one for
> the MATT framework.
>
> ### The opcodes
>
> case OP_CHECKINPUTCONTRACTVERIFY:
> {
> // OP_CHECKINPUTCONTRACTVERIFY is only available in Tapscript
> if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0)
> return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
> // (x d -- )
> if (stack.size() < 2)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> valtype& x = stacktop(-2);
> valtype& d = stacktop(-1);
> if (x.size() != 32 || d.size() != 32)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> const XOnlyPubKey nakedXOnlyKey{Span{x.data(), x.data()
> + 32}};
> const uint256 data(d);
> if (!execdata.m_internal_key.has_value())
> return set_error(serror, SCRIPT_ERR_UNKNOWN_ERROR); // TODO
> // Verify that tweak(lift_x(x), d) equals the internal pubkey
> if (!execdata.m_internal_key.value().CheckDoubleTweak(nakedXOnlyKey, &data,
> nullptr))
> return set_error(serror, SCRIPT_ERR_WRONGCONTRACTDATA);
> popstack(stack);
> popstack(stack);
> }
> break;
> case OP_CHECKOUTPUTCONTRACTVERIFY:
> {
> // OP_CHECKOUTPUTCONTRACTVERIFY is only available in Tapscript
> if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0)
> return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
> // (out_i x taptree d -- )
> if (stack.size() < 4)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> int out_i = CScriptNum(stacktop(-4), fRequireMinimal).getint();
> valtype& x = stacktop(-3);
> valtype& taptree = stacktop(-2);
> valtype& d = stacktop(-1);
> auto outps = checker.GetTxvOut();
> // Return error if the evaluation context is unavailable
> if (!outps)
> return set_error(serror, SCRIPT_ERR_UNKNOWN_ERROR); // TODO
> if (x.size() != 32 || taptree.size() != 32 || (d.size() != 0 && d.size() !=
> 32))
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> if
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
Thanks for this Andrew. > What commentary does there need to be? There doesn't "need" to be explanations about anything. There doesn't "need" to be any review comments whatsoever from anybody. But a world where reviewers explain what they've done to satisfy themselves that a pull request is ready to merge and a world where maintainers explain their thought process behind a merge decision is much easier to follow and much more scalable than the current black box where people see pull requests being self merged by a maintainer with no ACKs within a day of it being opened. Most likely these decisions make sense (low risk, unlikely to be reviewed by anybody else, blocking other pull requests etc). But more and more people are funded to work on Core and increasingly they seem to stick to their own mini projects and not review anybody else's work. Of course you can't put the responsibility for this entirely down to maintainers but the black box isn't scalable. Maintainers (presumably) have private discussions and so know how best to spend their review time. Everyone else (especially new contributors) are playing an uninformed and in the dark lottery with how they spend their review time (to the extent that they allocate any). > There are currently 320 open PRs and 366 open issues. I wake up every morning to 150+ email notifications containing everything that went on overnight, and throughout the day, I typically get hundreds more. Indeed. All the more reason for more and higher quality public communication. If you struggle and you're in those private discussions with other maintainers on merge decisions and ready for merge discussions how do you think everyone is trying to assess how to spend their time? It is even more bewildering. As far as I know most of the current maintainers haven't worked on other projects or in the private sector for a sustained period of time but the way other projects and businesses function is that those with the most experience and most responsibilities are able to manage and provide guidance to those with less experience and less responsibilities. I'm sure this goes on within Brink if you've been anointed but this is supposed to be an open source project. If everything is done in private conversations and everything other than the code is open source it is pretty much a façade. It is very hard to make meaningful contributions without getting anointed. Those who do get anointed very early in their careers seem especially bad at hoarding information, refusing to do anything in public and not assisting those who haven't been anointed. > Things can simply fall through the cracks. > With several long time maintainers stepping away, this may be a factor in PRs taking longer to get merged as the remaining maintainers may be less familiar with the parts of the codebase that were previously maintained by someone else. > Requiring maintainers to have to write explanations for every single merge is simply going to increase the burden on them and increase the rate of burnout and resignations. > We've had too many maintainers step down already. This all points to a a need for additional maintainers (assuming they are sufficiently competent and qualified). We had a potential maintainer (Vasil) come forward (long term contributor, made significant contributions over a number of years, a qualified reviewer, contributes to a part of the codebase that current maintainers aren't very familiar with, ACKed by maintainers and long term contributors) and it was blocked. How does that make sense? You seem to want it both ways. We can't ask maintainers to meet higher standards because there's a shortage and they're close to burning out. But there's no need to add a new maintainer. I've responded to the parts I disagree with and see inconsistencies with but generally I thought it was a very thoughtful and informative response so thank you. Of the current maintainers you seem to me to be one of (if not the) most responsive and open to public discussion on the project. I've learnt a tonne from your StackExchange posts and Twitch streams that are all public/open source that you do in addition to your contributions and maintenance of Core. Thanks Michael -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Wednesday, April 19th, 2023 at 22:33, Andrew Chow via bitcoin-dev wrote: > Responses in-line. > Note that the opinions expressed in this email are my own and are not > representative of what other maintainers think or believe. > > On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev wrote: > > > Communication has been a challenge on Bitcoin Core for what I can >
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
Hi AJ > Competition is the only answer to concerns about the bad effects from a > monopoly. Well one can first make suggestions and requests to the monopoly and see if the monopoly is open to them. In the case of bitcoin-inquisition/default signet I like the idea of a group who are interested in following and testing proposed future consensus changes working on the same fork of Core / same signet blockchain. But I've asked on a number of occasions now what the thinking is in terms of criteria for merging a proposed default policy change or a proposed consensus change (progress on BIP, level of review, a work in progress / still in flux / essentially finalized unless a problem is identified) and you haven't been willing to discuss it. So it is essentially the same black box model of maintainership we see on Core. As far as I know you could wake up one day and just merge all open pull requests to the bitcoin-inquisition repo because you're bored. On a custom signet do whatever you want. On the default signet that we're trying to build an ecosystem around, get block explorers to support, can be connected to through the default config in Core etc merge decisions essentially being subject to the whims of AJ doesn't seem ideal to me. The brunt of having to deal with the CTV activation chaos fell on me (not a long term contributor, unfunded) because few wanted to get involved so it would be nice if lessons were learned and we don't have a soft fork proposal merged onto default signet, a bunch of transactions generated to simulate demand and then this used to justify another contentious soft fork activation attempt on mainnet. When there are vacuums of communication from maintainers and long term contributors it just invites unnecessary chaos. Thanks Michael -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Thursday, April 20th, 2023 at 03:27, Anthony Towns wrote: > On Tue, Apr 18, 2023 at 12:40:44PM +, Michael Folkson via bitcoin-dev > wrote: > > > I do think the perception that it is “the one and only” staging > > ground for consensus changes is dangerous > > > If you think that about any open source project, the answer is simple: > create your own fork and do a better job. Competition is the only answer > to concerns about the bad effects from a monopoly. (Often the good effects > from cooperation and collaboration -- less wasted time and duplicated > effort -- turn out to outweigh the bad effects, however) > > In any event, inquisition isn't "the one and only staging ground for > consensus changes" -- every successful consensus change to date has > been staged through the developers' own repo then the core PR process, > and that option still exists. > > Cheers, > aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
ave the same or work similarly. Sometimes > the unresponsiveness could be to avoid controversies and heated debates that > go off-topic. > > > One farcical recent example 0 was the pull request to add Vasil Dimov as a > > maintainer where despite many ACKs from other maintainers and other long > > term contributors two maintainers (fanquake and Gloria) refused to discuss > > it on the pull request or on IRC. It took almost 5 months for Gloria to > > comment on the pull request despite many requests from me on the PR and on > > IRC. I even requested that they attend the weekly Core Dev IRC meeting to > > discuss it which they didn’t attend. > > > - Maintainers should be free to avoid involvement in a pull request. As long > as a subset of maintainers have an opinion on the pull request, things should > be fine. > - I agree with Gloria's comment: "I had not NACKed this either because my > opinion could change over time, NACKs are sometimes needlessly interpreted as > personal attacks, and Brink has been antagonized on Twitter each time > multiple grantees have similar opinions about this. So I'll add that if you > wish to have more decentralization in Bitcoin Core funding, you can start by > creating a nonprofit, gathering donations, and funding somebody who works on > Bitcoin Core." Last part of this comment also solves the problem shared in > other thread related to new bitcoin implementation. Brink needs some > competition and bitcoin core needs more reviewers. > - I also agree with Andrew's comment: "frankly, I think opinions aren't being > shared because of potential backlash from aggressive users such as yourself > and bytes144" > > > Maintainers and long term contributors (if they commented at all) were > > gently enthusiastic (Concept ACKing etc) without ACKing that it was ready > > to merge. A long term observer of the Core repo would have known that it > > wasn’t ready to merge or ready to attempt to activate (especially given it > > was a consensus change) but a casual observer would have only seen Concept > > ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated > > the numbers on the utxos.org site 4 signalling support for a soft fork > > activation attempt. > > > - I don't see anything wrong with sharing honest opinion if someone agrees > with the concept. It does not make a pull request ready to get merged. > - utxos.org is an external site maintained by Jeremy with opinions on BIP > 119. Everyone is free to maintain such lists and I think you had also created > one as GitHub gist. > > > I will probably write about bitcoin-inquisition/default signet in a future > > email as I do think the perception that it is “the one and only” staging > > ground for consensus changes is dangerous 6 if the maintainer(s) on that > > project have the same inclinations as a subset of the Core maintainers. > > > This perception (if exists) can be killed by creating a custom signet, > maintaining it differently, get more reviews, testing and share details with > community regularly. > > /dev/fd0 > floppy disk guy > > 0: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1381654564 > 1: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-01-12#883748 > > > Sent with Proton Mail secure email. > > --- Original Message --- > On Tuesday, April 18th, 2023 at 6:10 PM, Michael Folkson via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > > > Communication has been a challenge on Bitcoin Core for what I can tell the > > entire history of the project. Maintainers merge a pull request and provide > > no commentary on why they’ve merged it. Maintainers leave a pull request > > with many ACKs and few (if any) NACKs for months and provide no commentary > > on why they haven't merged it. I can only speculate on why and it probably > > depends on the individual maintainer. Sometimes it will be poor > > communication skills, sometimes it will be a desire to avoid > > accountability, sometimes it will be fear of unreasonable and spiteful > > legal action if they mistakenly merge a pull request that ends up > > containing a bug. But search through the pull requests on Bitcoin Core and > > you will rarely see a rationale for a merge decision. The difference > > between say previous maintainers like Wladimir and some of the current > > maintainers is that previous maintainers were extremely responsive on IRC. > > If you disagreed with a merge decision or thought it had been merged > > prematurely they would be happ
Re: [bitcoin-dev] A new Bitcoin implementation integrated with Core Lightning
Hi Kostas > Could you please point me to a resource that describes the default policy > changes (that are happening for lightning)? I have seen discussions here and > there but it would help if they are aggregated somewhere for reviewing. It is hard to follow because most of the discussions aren't on public channels, a number of the devs working on these proposed default policy changes aren't taking the BIP process seriously and no one is willing to discuss the criteria for merging default policy changes (and consensus changes for that matter) into bitcoin-inquisition (default signet). In addition the work (to the extent that it is public) is scattered all over the place. So yeah it seems like a mess to me from the perspective of someone is seeking to follow, review and monitor it. This Bitcoin StackExchange post [0] is my first attempt to do what you're looking for and these Bitcoin Core PR review clubs [1], [2] were really good from Gloria. But yeah the BIP process (as I've said a thousand times and been ignored) is the place to hammer out specifications for complex things like default policy proposals and when people don't care about formalizing specifications it becomes very hard for people like you and me to follow. > Separation of concerns always makes sense to manage complexity. One would > need to have really strong incentives to counter the complexity argument. >> I might be missing some context here but what would the actual benefit of >> integrating them be? Not having to install lightning node separately and >> maybe a more intuitive UX? As I say in the original email having two separate P2P networks and two separate P2P protocols (perhaps) doesn't make much sense if all (or most of the nodes) are both full nodes and Lightning nodes. A testing framework that integrates both base layer and Lightning tests could potentially be easier to track edge cases which fall in the grey area between base layer and Lightning but are critically important for Lightning. A Core wallet that doesn't support Lightning doesn't make much sense in a world where transaction fees are really high and you have to use Lightning unless you are transferring huge amounts. I agree with you that these arguments have to be strong to counter the separation of concerns angle and maybe it is too early to consider it. But if moving in the direction of more widely used consensus compatible forks of Core then having Lightning integrated could make it an attractive option. > PS. Besides, the amount of effort would be significant. Wouldn't that effort > be better spent on, say, separating the consensus logic (i.e. a second > libbitcoinkernel attempt)? libbitcoinkernel can achieve smaller (and still important) goals but I'm skeptical that the more ambitious goal of having lots of different implementations in different languages with libbitcoinkernel at its core and not having to worry about consensus bugs will be reached in the medium term. As we saw with the recent btcd/lnd bugs [3] consensus bugs can crop up in places you might not expect. In that case it was a wire parsing library that you wouldn't expect to be part of a libbitcoinkernel. So if you're still going to encounter consensus bugs outside of libbitcoinkernel there isn't much point (in my view) in using it for alternative implementations. Thanks Michael [0]: https://bitcoin.stackexchange.com/questions/117315/what-and-where-are-the-current-status-of-the-bip-125-replacement-the-v3-policy [1]: https://bitcoincore.reviews/25038 [2]: https://bitcoincore.reviews/25038-2 [3]: https://bitcoin.stackexchange.com/questions/115527/what-is-the-october-2022-bug-in-lnd-what-caused-it-and-what-would-prevent-a-sim -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Wednesday, April 19th, 2023 at 10:05, Kostas Karasavvas wrote: > Hi Michael, > > On Wed, Apr 19, 2023 at 2:40 AM Michael Folkson via bitcoin-dev > wrote: > >> Any thoughts on this from the Core Lightning contributors? The way I see it >> with upcoming proposed changes to default policy (primarily though not >> exclusively for Lightning) and a soft fork activation attempt of APO/APOAS >> (primarily though not > > Could you please point me to a resource that describes the default policy > changes (that are happening for lightning)? I have seen discussions here and > there but it would help if they are aggregated somewhere for reviewing. > >> exclusively for Lightning) that a tighter coupling between the full node and >> the Lightning node could eventually make sense. In a world where transaction >> fees were much higher you'd think almost eve
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
Hi Erik > yes, the code itself was far less contentious than the weird stab at forking > the network > > there remains a real chance that bip 119 is the simplest and most flexible > and reasonably safe covenant tech for many use cases > > although im partial to 118 as well because lightning is a killer app and it > makes batch channels more efficient This is moving off the intended subject of the email although latest thoughts on BIP 118 and BIP 119 are an interesting separate topic. Perhaps start a new thread? The latest afaik is that both have been merged in bitcoin-inquisition [0] (default signet) and James O'Beirne concluded that he needed BIP 119/OP_CTV for his latest vault design that includes a new proposed opcode OP_VAULT (BIP 345) [1]. Designing and building vaults with the various proposed opcodes and sighash flags (and Simplicity when it is ready) is definitely what I hoped to see after the chaos of the attempted CTV activation. Hopefully more people will be drawn into this research and development area, I think it is a really interesting one [2] so I'm a bit bemused more people aren't following James and the Revault team and doing their own research and experimentation. I think darosior's (Revault) current view [3] is BIP 118/APO is sufficient for the vaults he wants to build. But yeah needs more informed views and you only really get a more informed view by trying to design and build things and realizing what you need or what is missing. It isn't convincing to embark on a soft fork activation process just because a couple of informed individuals want it. Thanks Michael [0]: https://github.com/bitcoin-inquisition/bitcoin [1]: https://github.com/bitcoin/bips/pull/1421 [2]: https://www.youtube.com/watch?v=S2lTfS5qMJE [3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020276.html -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Wednesday, April 19th, 2023 at 01:56, Erik Aronesty wrote: > yes, the code itself was far less contentious than the weird stab at forking > the network > > there remains a real chance that bip 119 is the simplest and most flexible > and reasonably safe covenant tech for many use cases > > although im partial to 118 as well because lightning is a killer app and it > makes batch channels more efficient > > On Tue, Apr 18, 2023, 7:39 PM Michael Folkson via bitcoin-dev > wrote: > >> Communication has been a challenge on Bitcoin Core for what I can tell the >> entire history of the project. Maintainers merge a pull request and provide >> no commentary on why they’ve merged it. Maintainers leave a pull request >> with many ACKs and few (if any) NACKs for months and provide no commentary >> on why they haven't merged it. I can only speculate on why and it probably >> depends on the individual maintainer. Sometimes it will be poor >> communication skills, sometimes it will be a desire to avoid accountability, >> sometimes it will be fear of unreasonable and spiteful legal action if they >> mistakenly merge a pull request that ends up containing a bug. But search >> through the pull requests on Bitcoin Core and you will rarely see a >> rationale for a merge decision. The difference between say previous >> maintainers like Wladimir and some of the current maintainers is that >> previous maintainers were extremely responsive on IRC. If you disagreed with >> a merge decision or thought it had been merged prematurely they would be >> happy to discuss it on IRC. In present times at least a subset of the >> current maintainers are not responsive on IRC and will refuse to discuss a >> merge decision. One farcical recent example [0] was the pull request to add >> Vasil Dimov as a maintainer where despite many ACKs from other maintainers >> and other long term contributors two maintainers (fanquake and Gloria) >> refused to discuss it on the pull request or on IRC. It took almost 5 months >> for Gloria to comment on the pull request despite many requests from me on >> the PR and on IRC. I even requested that they attend the weekly Core Dev IRC >> meeting to discuss it which they didn’t attend. >> >> A pull request to add a maintainer isn’t a normal pull request. Generally >> pull requests contain a lot more lines of code than a single line adding a >> trusted key. Not merging a pull request for a long period of time can be >> extremely frustrating for a pull request author especially when maintainers >> and long term contributors don’t comment on the pull request and the pull >> request is st
Re: [bitcoin-dev] A new Bitcoin implementation integrated with Core Lightning
Any thoughts on this from the Core Lightning contributors? The way I see it with upcoming proposed changes to default policy (primarily though not exclusively for Lightning) and a soft fork activation attempt of APO/APOAS (primarily though not exclusively for Lightning) that a tighter coupling between the full node and the Lightning node could eventually make sense. In a world where transaction fees were much higher you'd think almost every full node would also want to be a Lightning node and so the separation of concerns would make less sense. Having two separate P2P networks and two separate P2P protocols also wouldn't make much sense in this scenario. You could obviously still opt out of Lightning P2P messages if you weren't interested in Lightning. The alternative would be just to focus on Knots style consensus compatible forks of Core with limited additional functionality. But I think we've reached the point of no return on Core dominance and not having widely used "distros". As the ecosystem scales systems and processes should be constantly evolving and improving and to me if anything Core's seem to be going backwards. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Saturday, January 14th, 2023 at 20:26, Michael Folkson wrote: > I tweeted this [0] back in November 2022. > > "With the btcd bugs and the analysis paralysis on a RBF policy option in Core > increasingly thinking @BitcoinKnots and consensus compatible forks of Core > are the future. Gonna chalk that one up to another thing @LukeDashjr was > right about all along." > > A new bare bones Knots style Bitcoin implementation (in C++/C) integrated > with Core Lightning was a long term idea I had (and presumably many others > have had) but the dysfunction on the Bitcoin Core project this week (if > anything it has been getting worse over time, not better) has made me start > to take the idea more seriously. It is clear to me that the current way the > Bitcoin Core project is being managed is not how I would like an open source > project to be managed. Very little discussion is public anymore and decisions > seem to be increasingly made behind closed doors or in private IRC channels > (to the extent that decisions are made at all). Core Lightning seems to have > the opposite problem. It is managed effectively in the open (admittedly with > fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin > Core does. Regardless, selfishly I at some point would like a bare bones > Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin > Core codebase has collected a lot of cruft over time and the ultra > conservatism that is needed when treating (potential) consensus code seems to > permeate into parts of the codebase that no one is using, definitely isn't > consensus code and should probably just be removed. > > The libbitcoinkernel project was (is?) an attempt to extract the consensus > engine out of Core but it seems like it won't achieve that as consensus is > just too slippery a concept and Knots style consensus compatible codebase > forks of Bitcoin Core seem to still the model. To what extent you can safely > chop off this cruft and effectively maintain this less crufty fork of Bitcoin > Core also isn't clear to me yet. > > Then there is the question of whether it makes sense to mix C and C++ code > that people have different views on. C++ is obviously a superset of C but > assuming this merging of Bitcoin Core and Core Lightning is/was the optimal > final destination it surely would have been better if Core Lightning was > written in the same language (i.e. with classes) as Bitcoin Core. > > I'm just floating the idea to (hopefully) hear from people who are much more > familiar with the entirety of the Bitcoin Core and Core Lightning codebases. > It would be an ambitious long term project but it would be nice to focus on > some ambitious project(s) (even if just conceptually) for a while given > (thankfully) there seems to be a lull in soft fork activation chaos. > > Thanks > Michael > > [0]: > https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw > > -- > Michael Folkson > Email: michaelfolkson at [protonmail.com](http://protonmail.com/) > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
Communication has been a challenge on Bitcoin Core for what I can tell the entire history of the project. Maintainers merge a pull request and provide no commentary on why they’ve merged it. Maintainers leave a pull request with many ACKs and few (if any) NACKs for months and provide no commentary on why they haven't merged it. I can only speculate on why and it probably depends on the individual maintainer. Sometimes it will be poor communication skills, sometimes it will be a desire to avoid accountability, sometimes it will be fear of unreasonable and spiteful legal action if they mistakenly merge a pull request that ends up containing a bug. But search through the pull requests on Bitcoin Core and you will rarely see a rationale for a merge decision. The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC. If you disagreed with a merge decision or thought it had been merged prematurely they would be happy to discuss it on IRC. In present times at least a subset of the current maintainers are not responsive on IRC and will refuse to discuss a merge decision. One farcical recent example [0] was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend. A pull request to add a maintainer isn’t a normal pull request. Generally pull requests contain a lot more lines of code than a single line adding a trusted key. Not merging a pull request for a long period of time can be extremely frustrating for a pull request author especially when maintainers and long term contributors don’t comment on the pull request and the pull request is stuck in “rebase hell”. Clearly it is the lesser evil when compared to merging a harmful or bug ridden pull request but poor non-existent communication is not the only way to prevent this. Indeed it creates as many problems as it solves. Another farcical recent(ish) example was the CTV pull request [1] that ultimately led to a contentious soft fork activation attempt that was called off at the last minute. If you look at the comments on the pull request there were 3 individuals (including myself) who NACKed the pull request and I think it is fair to say that none of us would be considered long term contributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for continuing to pursue a soft fork activation attempt when it was clear it was contentious [3] but if you look at the pull request comments it certainly isn’t clear it was. Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site [4] signalling support for a soft fork activation attempt. I set out originally to write about the controls and processes around merges on the default signet (bitcoin-inquisition [5]) but it quickly became obvious to me that if communication around Core merges/non-merges is this weak you can hardly expect it to be any better on bitcoin-inquisition/default signet where there is no real monetary value at stake. I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous [6] if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers. As I stated at the beginning there is an element to this which is not individual(s) specific and an adverse reaction to outright malicious actors external to any of these projects. I do not think any of the current maintainers on Core or bitcoin-inquisition are outright malicious even if a subset of them consistently frustrate me with their lack of transparency and accountability. But this issue isn't going away and I'm sure we'll hear more on this from others in the coming months. To me it is a straight choice of taking transparency and accountability much more seriously or failing that investing more heavily (time and resources) in consensus compatible forks of Core and treating Core like it is a proprietary "open source" project where merge decisions are not explained or justified in the open. [0]: https://github.com/bitcoin/bitco
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
Hi Andrew > There is a bug in Taproot that allows the same Tapleaf to be repeated > multiple times in the same Taproot, potentially at different Taplevels > incurring different Tapfee rates. >> The countermeasure is that you should always know the entire Taptree when >> interacting with someone's Tapspend. I wouldn't say it is a "bug" unless there is a remedy for the bug that wasn't (and retrospectively should have been) included in the Taproot design. In retrospect and assuming you could redesign the Taproot consensus rules again today would you prevent spending from a valid P2TR address if a repeated Tapleaf hash was used to prove that a spending path was embedded in a Taproot tree? That's the only thing I can think of to attempt to remedy this "bug" and it would only be a partial protection as proving a spending path exists within a Taproot tree only requires a subset of the Tapleaf hashes. I only point this out because there seems to be a push to find "bugs" and "accidental blowups" in the Taproot design currently. No problem with this if there are any, they should definitely be highlighted and discussed if they do exist. The nearest to a possible inferior design decision thus far that I'm aware of is x-only pubkeys in BIP340 [0]. Thanks Michael [0]: https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340 -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via bitcoin-dev wrote: > There is a bug in Taproot that allows the same Tapleaf to be repeated > multiple times in the same Taproot, potentially at different Taplevels > incurring different Tapfee rates. > > The countermeasure is that you should always know the entire Taptree when > interacting with someone's Tapspend. > > On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev > wrote: > >> Some people highlighted some minor problems with my last email: >> >> On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via bitcoin-dev >> wrote: >>> >>> >>> >>> [1] https://bitcoin.sipa.be/miniscript/ >>> [2] In Taproot, if you want to prevent signatures migrating to another >>> branch or within a branch, you can use the CODESEPARATOR opcode >>> which was redisegned in Taproot for exactly this purpose... we >>> really did about witness malleation in its design! >> >> In Taproot the tapleaf hash is always covered by the signature (though >> not in some ANYONECANPAY proposals) so you can never migrate signatures >> between tapbranches. >> >> I had thought this was the case, but then I re-confused myself by >> reading BIP 341 which has much of the sighash specified, but not >> all of it! The tapleaf hash is added in BIP 342. >> >>> >>> If you want to prevent signatures from moving around *within* a >>> branch, >>> >> >> And this sentence I just meant to delete :) >> >> -- >> Andrew Poelstra >> Director of Research, Blockstream >> Email: apoelstra at wpsoftware.net >> Web: https://www.wpsoftware.net/andrew >> >> The sun is always shining in space >> -Justin Lewis-Webster >> >> ___ >> 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] [Lightning-dev] A new Bitcoin implementation integrated with Core Lightning
Hi alicexbt Thanks for the suggestion. I'll take a look at the branch. I'm personally pretty bullish on Lightning and Core Lightning is criminally underused. Plus it is more exciting (and hopefully will attract more contributors) to try something ambitious than just trim Core. I'll see if it is something the Core Lightning contributors might be interested in helping out on. I remember that Rusty said on a podcast that if he had another life he'd have liked to have worked on Core. This way he could potentially do both :) Thanks Michael -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Sunday, January 15th, 2023 at 12:58, alicexbt wrote: > Hi Michael, > > If I were to fork bitcoin core and maintain an implementation, I wouldn't > integrate any lightning implementation with it. Instead remove some things > from bitcoin core and keep it simple. There is also scope for improving > privacy. Example: https://github.com/bitcoinknots/bitcoin/issues/50 > > You might find the commits in this branch interesting if you are looking to > remove things from bitcoin core and maintain an implementation with no gui, > wallet, less RPCs etc. > > https://github.com/jeremyRubin/bitcoin/commits/delete-it-all > > > /dev/fd0 > floppy disc guy > > Sent with Proton Mail secure email. > > --- Original Message --- > On Sunday, January 15th, 2023 at 1:56 AM, Michael Folkson via Lightning-dev > lightning-...@lists.linuxfoundation.org wrote: > > > > > I tweeted this 0 back in November 2022. > > > > "With the btcd bugs and the analysis paralysis on a RBF policy option in > > Core increasingly thinking @BitcoinKnots and consensus compatible forks of > > Core are the future. Gonna chalk that one up to another thing @LukeDashjr > > was right about all along." > > > > A new bare bones Knots style Bitcoin implementation (in C++/C) integrated > > with Core Lightning was a long term idea I had (and presumably many others > > have had) but the dysfunction on the Bitcoin Core project this week (if > > anything it has been getting worse over time, not better) has made me start > > to take the idea more seriously. It is clear to me that the current way the > > Bitcoin Core project is being managed is not how I would like an open > > source project to be managed. Very little discussion is public anymore and > > decisions seem to be increasingly made behind closed doors or in private > > IRC channels (to the extent that decisions are made at all). Core Lightning > > seems to have the opposite problem. It is managed effectively in the open > > (admittedly with fewer contributors) but doesn't have the eyeballs or the > > usage that Bitcoin Core does. Regardless, selfishly I at some point would > > like a bare bones Bitcoin and Lightning implementation integrated in one > > codebase. The Bitcoin Core codeb ase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed. > > > > The libbitcoinkernel project was (is?) an attempt to extract the consensus > > engine out of Core but it seems like it won't achieve that as consensus is > > just too slippery a concept and Knots style consensus compatible codebase > > forks of Bitcoin Core seem to still the model. To what extent you can > > safely chop off this cruft and effectively maintain this less crufty fork > > of Bitcoin Core also isn't clear to me yet. > > > > Then there is the question of whether it makes sense to mix C and C++ code > > that people have different views on. C++ is obviously a superset of C but > > assuming this merging of Bitcoin Core and Core Lightning is/was the optimal > > final destination it surely would have been better if Core Lightning was > > written in the same language (i.e. with classes) as Bitcoin Core. > > > > I'm just floating the idea to (hopefully) hear from people who are much > > more familiar with the entirety of the Bitcoin Core and Core Lightning > > codebases. It would be an ambitious long term project but it would be nice > > to focus on some ambitious project(s) (even if just conceptually) for a > > while given (thankfully) there seems to be a lull in soft fork activation > > chaos. > > > > Thanks > > Michael > > > > -- > > Michael Folkson > > Email: michaelfolkson at protonmail.com > > Keybase: michaelfolkson > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] A new Bitcoin implementation integrated with Core Lightning
I saw it was announced, yes. The author is brilliant, he has now managed two alternative implementations of Core in two different languages :) The problem though and why I and many others think the Knots style fork of Core is the better option is because you avoid reimplementing consensus code in a different language. If you're ultra conservative about consensus code you either want to run Core in parallel with your alternative implementation to check they don't go out of consensus or you want to run the same consensus code as Core in a Knots like fork. Hence a Knots like fork of Core in C++ integrated with Core Lightning in C seems like the better option to me for serious running in production like use cases. -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Saturday, January 14th, 2023 at 20:34, Fabian wrote: > Hi Michael, > > have you seen Mako? It might at least be a good start for what you would like > to achieve: https://github.com/chjj/mako > > Best, > Fabian > --- Original Message --- > On Saturday, January 14th, 2023 at 9:26 PM, Michael Folkson via Lightning-dev > wrote: > >> I tweeted this [0] back in November 2022. >> >> "With the btcd bugs and the analysis paralysis on a RBF policy option in >> Core increasingly thinking @BitcoinKnots and consensus compatible forks of >> Core are the future. Gonna chalk that one up to another thing @LukeDashjr >> was right about all along." >> >> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated >> with Core Lightning was a long term idea I had (and presumably many others >> have had) but the dysfunction on the Bitcoin Core project this week (if >> anything it has been getting worse over time, not better) has made me start >> to take the idea more seriously. It is clear to me that the current way the >> Bitcoin Core project is being managed is not how I would like an open source >> project to be managed. Very little discussion is public anymore and >> decisions seem to be increasingly made behind closed doors or in private IRC >> channels (to the extent that decisions are made at all). Core Lightning >> seems to have the opposite problem. It is managed effectively in the open >> (admittedly with fewer contributors) but doesn't have the eyeballs or the >> usage that Bitcoin Core does. Regardless, selfishly I at some point would >> like a bare bones Bitcoin and Lightning implementation integrated in one >> codebase. The Bitcoin Core codebase has collected a lot of cruft over time >> and the ultra conservatism that is needed when treating (potential) >> consensus code seems to permeate into parts of the codebase that no one is >> using, definitely isn't consensus code and should probably just be removed. >> >> The libbitcoinkernel project was (is?) an attempt to extract the consensus >> engine out of Core but it seems like it won't achieve that as consensus is >> just too slippery a concept and Knots style consensus compatible codebase >> forks of Bitcoin Core seem to still the model. To what extent you can safely >> chop off this cruft and effectively maintain this less crufty fork of >> Bitcoin Core also isn't clear to me yet. >> >> Then there is the question of whether it makes sense to mix C and C++ code >> that people have different views on. C++ is obviously a superset of C but >> assuming this merging of Bitcoin Core and Core Lightning is/was the optimal >> final destination it surely would have been better if Core Lightning was >> written in the same language (i.e. with classes) as Bitcoin Core. >> >> I'm just floating the idea to (hopefully) hear from people who are much more >> familiar with the entirety of the Bitcoin Core and Core Lightning codebases. >> It would be an ambitious long term project but it would be nice to focus on >> some ambitious project(s) (even if just conceptually) for a while given >> (thankfully) there seems to be a lull in soft fork activation chaos. >> >> Thanks >> Michael >> >> [0]: >> https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw >> >> -- >> Michael Folkson >> Email: michaelfolkson at [protonmail.com](http://protonmail.com/) >> Keybase: michaelfolkson >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] A new Bitcoin implementation integrated with Core Lightning
I tweeted this [0] back in November 2022. "With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along." A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed. The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet. Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core. I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos. Thanks Michael [0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Roles and procedures around adding a bitcoin core maintainer
Hi alicexbt There does seem to be some confusion on this which I'm going to look into. I don't think ranting and raving or throwing toys out the pram on the mailing list is the productive way to go though. I'll chat to some people offline and see what the confusion is and hopefully this can be resolved without unnecessary drama. I'll respond in the new year. I don't know if you celebrate but if you do Happy Holidays. Thanks Michael -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Monday, December 19th, 2022 at 23:58, alicexbt via bitcoin-dev wrote: > Hi Bitcoin Developers, > > List of present bitcoin core maintainers: > > Username > > Focus Area > > MarcoFalke > > General, QA > > fanquake > > General, Build > > hebasto > > General, UI/UX > > achow101 > > General, Wallet > > glozow > > General, Mempool > > Last 2 developers that stepped down as bitcoin core maintainer: > > Username > > - > > sipa > > laanwj > > Process followed in adding last maintainer: > > 1) fanquake [nominated][0] glowzow as rbf/mempool/validation maintainer. > > 2) It was discussed in an IRC [meeting][1] and most of the developers agreed > to add her as new maintainer except mild NACK from Jeremy Rubin. Some > contributors did not like different opinions being shared in the meeting. > > 3) A [pull request][2] was opened by glowzow to add keys. There were several > ACKs, 2 NACKs and 1 meta concept NACK. > > My NACK: https://github.com/bitcoin/bitcoin/pull/25524#issuecomment-1172518409 > > NACK by jamesob: > https://github.com/bitcoin/bitcoin/pull/25524#issuecomment-1172570635 > > Meta concept NACK by luke-jr: > https://github.com/bitcoin/bitcoin/pull/25524#issuecomment-1175625779 > > Eventually everyone agreed to add glowzow as maintainer and improve the > process of adding maintainers. Pull request was merged by MarcoFalke. > > Initiatives to improve the process and documentation: > > 1) Jeremy opened a [pull request][3] and there were lot of disagreements with > the documentation. It was closed since a related PR with less changes could > be easy to agree upon. > > 2) Related [pull request][4] with minimal documentation was also closed by > Jeremy with a comment that desire to improve docs seems to be missing based > on reviews. > > 3) Jeremy opened an [issue][5] with title 'Call for Maintainer: P2P & > Networking + Privacy' which was changed later and 'Privacy' was removed. He > nominated jonatack and vasild was already self nominated so mentioned in the > pull request. Nobody appreciated this effort to nominate self or others for a > new maintainer. Later this was closed. > > 4) I had opened an [issue][6] with title Call for Maintainer: Privacy'. This > even involved privacy of contributors and not just bitcoin core. It received > some comments that made no sense and I eventually closed the issue. > > Process being followed for adding vasild as maintainer: > > 1) vasild volunteered to be a new maintainer on [IRC][7] > > 2) It was discussed in IRC [meeting][8], some developers ACKed it and there > were no issues. > > 3) A [pull request][9] was opened by vasild to add keys which is still open > and its been 4 months. There were already some ACKs from the IRC meeting and > pull request also received some ACKs (16 until now). fanquake, dergoegge and > JeremyRubin had some disagreements. Jeremy had recently withdrawn all > ACK/NACK from bitcoin core repository for some reasons, fanquake has not > replied yet and dergoegge had some new disagreements although don't mind if > the pull request is merged. > > 4) Earlier disagreements were related to scoping and it was changed by vasild > > 4) There was even a comment that disrespected vasild's contributions in > bitcoin core and we had to literally share pull requests in which vasild has > improved bitcoin core. > > 5) I tried adding the topic for a bitcoin core dev weekly meeting but did not > achieve anything. > > Since Bitcoin Core is the reference implementation for Bitcoin and used by > 90% nodes, what should be the ideal process or changes you would expect in > roles, procedures etc.? > > - 'Call for maintainers' issue should be opened if contributors or > maintainers need a new maintainer. > > - Discussion about nominated contributors in an IRC meeting where everyone is > allowed to share their opinion. > > - One of the nominated contributor that gets most ACKs could open pull > request to add keys. Everyone can ACK/NACK this PR with reasons. > > - Maintainers should be unbiased in merging these pull requests. > > - New maintainer should not be funded by the organization that already does > it for most of the maintainers. > > - Long term contributors that are not living in a first world country should > be encouraged. > > - Either we should agree every maintai
Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol
I think it best I leave this discussion to others then as something I've written has obviously offended you. I'll also leave it to others to assess whether I was disrespectful or attacking your character or quality of experience in that email. Someone working on the P2P or mempool part of the Bitcoin Core codebase for years is going to understand the code and the subtle trade-offs of mempool policy defaults better than you or I. I hate to break it to you. Just like you are going to understand Synonym's business and technology better than that P2P/mempool developer. We all have different skillsets and different experiences. > When I post in github, you mention I should be banned and you ignore my > substantive arguments. Pull requests on Bitcoin Core's GitHub repository are for technical review of the concept, approach and code contained within that pull request. Submitting your Concept (N)ACK and reasoning is perfectly fine as is opening a pull request with the same changes. But the general high level discussion (back and forth etc) you seem to want to have is much better suited here than on a Bitcoin Core pull request. It is impossible for the Bitcoin Core project to operate if the world's population aren't willing to follow project norms and want to have discussions on subjects that aren't within the scope of that pull request. I and others requested you go here and you initially refused and said you struggled to use this forum. But yeah I'm not interested in engaging a shouting match. So with regards to your questions I'll leave it to others to discuss them with you. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Sunday, December 11th, 2022 at 16:56, John Carvalho wrote: > While I appreciate your reference links, and will check them out (thanks!), I > do not appreciate your repeated takes about my character or quality of > experience. I have been in Bitcoin for 10 years, I build with it, I manage a > Bitcoin company with 8 engineers, and, modesty aside, there aren't very many > non-engineers that grasp how Bitcoin works as well as I do. I put lots of > time into Bitcoin, and do my best to scrutinize all concepts presented to me. > > When I post in github, you mention I should be banned and you ignore my > substantive arguments. If I post on the list here, you imply I am a noob, > have difficulty understanding, and that I'm biased by business. This is not > useful other than some, probably false, notion that maybe you can position > yourself as superior or myself as dismissable. > > My post is an analysis on incentives and how we understand them when > designing for Bitcoin. You explained a bit about what the mempool is for, and > some dynamics about it, but you may notice that doing something like > mempoolfullrbf is actually inconsistent with a goal of mempool harmony. It is > a disruptive change, therefore a tradeoff. The arguments for making that > tradeoff use some oversimplified concepts, in my opinion. > > So, I am questioning the quality of current theory, and showing how it might > be insufficient. > > - Do you think it is possible that a fully replaceable mempool, and > obsoletion of zero-conf (merchant/consumer) use cases could result in less > overall mining income? If not, why not? > - Could this, and other active management by Bitcoin Core engineers, result > in an overall less valuable, less useful Bitcoin, and is that bad for > miners/security? > - Do you think it is inconsistent that on one hand, Bitcoiners argue that > miners do not control Bitcoin, yet Bitcoin Core is biasing decisions to cater > to mining incentives over user incentives? Should miners do what users want, > and might that be their actual incentive? > - Do you think it is Core's place to influence or steer policy based on > speculation about what may happen in the future, even when it conflicts with > the present and past? > > *These* are the interesting questions. Do you have reasoned answers? > > You suggest you are comfortable outsourcing your understanding and decisions > to others, well I am not, and my post was meant to show some reasons why. It > is important that Bitcoiners question how, when, and whether Bitcoin software > is changed, regardless of their ability to create or audit code. > > Please analyze my ideas instead of me, thank you. Or, you could stay out of > it and outsource that to someone else as well. > > ~John > > On Sun, Dec 11, 2022 at 1:58 PM Michael Folkson > wrote: > >> Hey John >> >> There was a discussion [0] started by Lisa on the mailing list last year on >> whether there is any point to a full node maintaining a mempool last year >> which you may find interesting. I also recommend Gloria's presentation [1] >> from Adopting Bitcoin last year on transaction relay poli
Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol
Hey John There was a discussion [0] started by Lisa on the mailing list last year on whether there is any point to a full node maintaining a mempool last year which you may find interesting. I also recommend Gloria's presentation [1] from Adopting Bitcoin last year on transaction relay policy. I think those are better resources than anything I could write. But I guess I'd summarize it like this. The job of the P2P/mempool/policy protocol devs in setting defaults is to ensure anyone can effectively propagate a consensus valid transaction across the network ultimately making its way into miners' mempools without harming network health (full node uptime, DoS attacks etc) and to give higher layers built on top of the Bitcoin network the best chance to succeed. If they totally screwed up that job with the defaults or they were unable to cater for a particular use case within default policy then there is always the alternative of submitting consensus valid transactions directly to miners bypassing the P2P network entirely. But clearly it is much better if the P2P network functions smoothly and every transaction isn't forced to be directly submitted to a miner. It is policy too of course rather than consensus so if the full node operator wants to change from the defaults they are free to do so without risking being forked off the network or risking a chain split. > I know some of you may scoff at my bias for use cases like zero-conf, but > what I am trying to convey is a possible folly in active management, > speculation, and misapplied game theory that may permeate many Bitcoin Core > decisions and designs, even beyond the mempoolrbf / zero-conf debate. This stuff is difficult to follow and understand especially for people who haven't been into Bitcoin for long or are trying to build Bitcoin businesses full time, there are lots of subtleties. I've certainly struggled at many points in my learning journey and I'm sure I will continue to do so in future. So there is no scoffing (from me at least) at individuals trying to learn and businesses trying to thrive and provide services to their customers. Unfortunately there are occasionally scenarios where trade-offs have to be weighed up and decisions have to be made where some people aren't happy. You may disagree but I'm a lot more comfortable delegating responsibility for policy defaults to those who have worked full time in this area for years than say consensus changes where I think we all have a responsibility to ensure suboptimal or worse harmful changes aren't made to the consensus rules. I thought your input on the CTV discussion earlier in the year was really positive for example. On this topic though I think you could do with doing some more reading as there is a lot of past discussion. I'm sure those who work in this area full time would be happy to answer any questions you have if you do. Thanks Michael [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019572.html [1]: https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Saturday, December 10th, 2022 at 14:10, John Carvalho via bitcoin-dev wrote: > As we debate mempoolfullrbf, and I familiarize myself with related PRs from > engineers trying to reign in all of the possible behaviors that make it > inconsistent, I can’t help but think about how I see people using the term > “incentive-compatible” and how it seems to be awfully presumptive. > > The idea that a single Bitcoin transaction can be “incentive-compatible” by > simply restricting it to having a higher fee or fee rate is theoretical, > likely narrow, and not totally objective. RBF is inherently a > fee-minimization tool, which as a concept, as I understand > “incentive-compatibility” to be about miners in this context, makes RBF to be > anti-incentives; miners are fee maximizers. > > Miners want the most fees per block, and per lifetime, do they not? If > miners, and the mempool, are prioritizing for the smallest txns with the > highest fees, over the longest acceptable amount of time, this may conflict > with extra-mempool behaviors that result in more txns per block / per > lifetime. > > If this isn’t making sense yet, let me summarize by how such a problem would > express: a per-transaction fee-minimized, fully replaceable mempool as > policy, that appears to always require the highest fee per txn, but > ultimately includes less txns per block and less fees per lifetime. > Basically, less use cases, less users, less txns — all to enforce a > misunderstood theory and predictive speculation of what people want out of > the system and what miners will do about it. > > Simply, we probably want designs that fill blocks, an
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun > wallet developers) could work on a fork and run several nodes with such > functionality. Daniel Lipshitz has been working on BSV apparently [0] so I guess anything is possible with him. But as others have said turning a mempool policy issue (users have always been free to choose whatever policy they like with zero chain split risk) into a consensus issue and a contentious soft fork issue at that would not be advised. I highly doubt any of the long term Muun contributors would want to support a contentious soft fork and fight a consensus rule war on this. [0]: https://coingeek.com/gap600-ceo-daniel-lipshitz-talks-bsv-powered-stablecoins-on-coingeek-backstage-video/ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Monday, December 5th, 2022 at 16:12, Rijndael via bitcoin-dev wrote: > Good morning, > > That sounds like a very dangerous mode of operation. You can already hand a > transaction to a miner privately. I hand a transaction to a miner with some > reasonable fee, and then I go and broadcast a different transaction with a > minimal fee that spends the same inputs. The whole network (including the > miner I handed the tx to) could all be running with a strict first-seen > mempool policy, but we can still have a situation where the miner creates a > block with a different transaction from what you see in your mempool. If > anytime this happens, the nodes running your proposed rule drop the block, > then anyone can fork those nodes off the network whenever they want. > > Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt > to) promise consistency across mempools. Making a consensus rule that > enforces mempool consistency is a recipe for (unintended?) chainsplits. > > - rijndael > > On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote: > >> The only option I see against the attack Peter Todd is doing to opt-in RBF >> and 0Conf bitcoin usage is working on a bitcoin core implementation that >> stops propagation of full-rbf replaced blocks. Running multiple of such >> nodes on the network will add a risk to miners that enable full-rbf that >> would work as an incentive against that. >> >> Obviously that would require adding an option on bitcoin core (that is not >> technically but politically difficult to implement as Petter Todd already >> have commit access to the main repository). >> >> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun >> wallet developers) could work on a fork and run several nodes with such >> functionality. As far as I understand the percolation model, with 10 to 20 >> nodes running such a rule would create a significant risk for full-rbf >> miners. >> >> Regards. >> >> --- Eloy >> >> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev >> wrote: >> >>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev >>> wrote: On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev wrote: > FYI I've gotten a few hundred dollars worth of donations to this effort, > and > have raised the reward to about 0.02 BTC, or $400 USD at current prices. Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb): >>> >>> I'm turning it back on when (if) the mempool settles down. I've got more >>> than >>> enough donations to give another run at it (the majority was donated >>> privately >>> FWIW). There's a risk of the mempool filling up again of course; hard to >>> avoid >>> that. >>> >>> Right now of course it's really easy to double spend with the obvious >>> low-fee/high-fee method as the min relay fee keeps shifting. >>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c The block it was claimed in seems to have been about an hour after the default mempool filled up: https://twitter.com/murchandamus/status/1592274621977477120 That block actually seems to have included two alice.btc.calendar.opentimestamps.org txs, the other paying $7.88 (309sat/vb): https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf >>> >>> The second is because I turned down the full-rbf reward to more normal fee >>> levels. There's also another full-rbf double-spend from the Bob calendar, >>> along >>> the same lines: >>> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2 >>> >>> I double-spent the txin of the high fee tx that got mined. But I mistakenly >>> had >>> RBF enabled in that double-spend, so while it propagated initially, I >>> believe >>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb >>> tx. >>> Timeline (utc) to me looks like: - 13:12 -
Re: [bitcoin-dev] Custom signet for testing full RBF
Hi alicexbt Thanks for setting this up. Generally it seems to me like an excellent idea to set up custom signets (and/or get proposals enabled on the default signet) for testing and experimenting with new proposals. I have two questions. 1) In this particular case the -mempoolfullrbf configuration option is in the recent Bitcoin Core 24.0 release and so can be used both on mainnet and the default signet, testnet etc. What could be tested on this custom signet that can't be tested on the default signet with Bitcoin Core 24.0? Perhaps there are some things that are easier to test with a smaller custom signet network starting from scratch? 2) I know a number of people have struggled (e.g. [0], [1]) to get a custom signet set up. I think the CTV signet took a while to get set up too. It seems you followed the instructions on the Bitcoin wiki [2] for setting this one up? Was there anything you found difficult or was counterintuitive getting this custom signet set up? You are the sole block signer on this custom signet. How regularly are you mining blocks (e.g. strictly every 10 minutes, replicating the Poisson process on mainnet, adhoc etc?) Are you running this custom signet node on the same machine as a default signet, mainnet, testnet full node? I'm a little tentative to start joining custom signet networks on the same machine that is already running other nodes but perhaps there are no problems. I'm not sure yet if I have a use case in mind for this particular custom signet but I'm very interested in custom signet setup generally and the docs/resources to make this as easy as possible so thanks again for posting about this. Thanks Michael [0]: https://bitcoin.stackexchange.com/questions/114477/could-someone-share-with-me-some-documentations-or-sites-on-how-to-set-up-a-cust [1]: https://bitcoin.stackexchange.com/questions/114724/peer-discovery-on-a-custom-signet-custom-signetchallenge [2]: [0]: https://en.bitcoin.it/wiki/Signet#Custom_Signet -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Sunday, November 20th, 2022 at 08:36, alicexbt via bitcoin-dev wrote: > Hi Bitcoin Developers, > > I have setup a [custom signet][0] for testing full RBF. You can connect to > one or more of these nodes using `addnode`: > > 13.115.34.55 (issuer, full-rbf) > kfupbqwb2yvzzqjomfq5pkem553a6uzp2k73seqn4d46smy7azua.b32.i2p (rbf-optin) > luvczzzppiqnc2b7poivkxlugafe3uqaj245ebjqxtceio7poaorqcyd.onion (full-rbf) > > Example config: > > `signet=1 > signetchallenge=5121035daaa313aada6310340a242af17238cc1fd8849e875940bce65a60ac7e0e0ff751ae > proxy=127.0.0.1:9050 [signet] > addnode=luvczzzppiqnc2b7poivkxlugafe3uqaj245ebjqxtceio7poaorqcyd.onion > mempoolfullrbf=1` > > Example for a simple test case: > > - Run 2 nodes > - Connect node 1 with i2p node and use default opt-in rbf > - Connect node 2 with node 1 and onion node. This node should use > `mempoolfullrbf=1` in config and compile bitcoind using PR [#26454][1] branch > - Broadcast Tx1 using node 2 and replace with Tx2 using `bumpfee` RPC > > It will be fun to test with more nodes joining this custom signet. If anyone > interested to test, please post your bitcoin address in [full-rbf room][2]. > We can even setup an explorer if this experiment makes sense. > > [0]: https://en.bitcoin.it/wiki/Signet#Custom_Signet > [1]: https://github.com/bitcoin/bitcoin/pull/26454 > [2]: #full-rbf:matrix.org > > Sent with Proton Mail secure email. > > /dev/fd0 > ___ > 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] bitcoin-inquistion: evaluating soft forks on signet
Thanks for this AJ, especially the history on prior soft forks, the vast majority of which I was unclear on. > The point of doing it via signet and outside of core is there doesn't need to be any community consensus on soft forks. Unlike mainnet, signet sBTC isn't money, and it isn't permissionless; and unlike merging it into core, there isn't a risk of a mege having unintended side effects impacting mainnet operation. Agreed. I'm obviously much happier with proposed consensus changes being activated prematurely on a signet (default or custom) than on mainnet. > Because signet mining is a closed set (determined by the first block after genesis when the signetchallenge is locked in), signet soft forks always have gatekeepers. I'm also perfectly happy with the status quo of the default signet having block signers and gatekeepers for soft forks activated on the default signet. I'm more concerned with those gatekeepers being under pressure to merge unfinished, buggy soft fork proposals on the default signet which need to be reversed or changed disrupting all default signet users. The bar for mainnet activations is obviously much higher than for the default signet but the default signet does still need a bar. > If you don't want to risk any disruption, then regtest or a private signet is a better option. A global p2p network *always* has risk of disruption at some level or another. Right but disruption isn't boolean, it is a spectrum. It isn't disruption or zero disruption. The more soft fork proposals that are enabled on the default signet (and the more changes to those soft fork proposals pushed to the default signet) the higher the risk of a stalling blockchain (your signet node rejects a block the rest of the signet network accepts). The small number of block signers (currently 2) should prevent you being forked off entirely onto a different default signet chain with new mined blocks being added to your blockchain tip but your blockchain could stall. What should happen in this scenario? Say I'm a default signet full node runner and I don't want to run any code outside of say the Bitcoin Core repo. I don't care about the proposed soft forks being tested on the default signet, I just care about testing my application with the existing consensus rules on mainnet. However, my default signet blockchain has stalled because of some consensus rule adjustment (an effective hard fork) made by the signet miners and the block signers. I have to run a patch from bitcoin-inquisition to get my node adding blocks again? I'm essentially being forced to run code from bitcoin-inquisition or wait many months for a default signet checkpoint in a Core release. I looked into linux-next[0] which you mentioned as an interesting parallel in the Linux ecosystem on last week's Bitcoin Optech Twitter Spaces [1]. In that link linux-next is described as: "The linux-next tree is the holding area for patches aimed at the next kernel merge window." I guess I'd also want expectations to be tempered a little for consensus changes on bitcoin-inquisition versus say this description of linux-next. I don't know where the bar will be set for default signet soft fork activations by the block signers and the miners but wherever it is set it will be lower than mainnet. And to be considered for activation on mainnet these proposals do require community consensus if we want to minimize the risk of mainnet chain splits. There are no block signers or regularly updated checkpoints on mainnet. It is certainly possible that soft fork proposals that get activated on the default signet never get activated on mainnet and that being activated on the default signet offers no guarantees or even intentions/aims for the next Bitcoin Core (or any alternative implementation) release. I'd like to avoid the "my soft fork proposal has been activated on the default signet so you should expect it to be activated on mainnet within x months or y years" type thi ng. Thanks Michael [0]: https://www.kernel.org/doc/man-pages/linux-next.html [1]: https://twitter.com/bitcoinoptech/status/1574697495325974528?s=20&t=XWkpA459C9qxOOrBuP2fYA -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Sunday, October 2nd, 2022 at 07:12, Anthony Towns via bitcoin-dev wrote: > On Fri, Sep 16, 2022 at 05:15:45PM +1000, Anthony Towns via bitcoin-dev wrote: > > > So that's the concept. For practical purposes, I haven't yet merged > > either CTV or APO support into the bitcoin-inquisition 23.0 branch yet > > > I've now merged CTV and updated my signet miner to enforce both CTV and > APO (though you'd need to be either lucky or put some effort into it to > figure out how to get a CTV/APO transaction relayed to my miner). > > Updating APO to be compatible with CTV actually seems to have found a > previously unknown bug
Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
I've given this some extra thought and discussed with others who may later chime in on this thread. I'm now convinced this should be done on a custom public signet rather than on the default signet. SegWit was added to a new testnet (Segnet) for testing rather than the pre-existing testnet and I think future soft fork proposals should follow a similar approach. Even if there is community consensus on what soft fork proposals should be added to the default signet today (which may or may not be case) I find it highly unlikely this will always be the case. We then get into the situation where the block signers (currently AJ and Kalle) are the gatekeepers on what soft fork proposals are added. The default signet is directly supported with the -signet flag in Bitcoin Core. Even if we are moving the proposed soft fork code to an external repo (to avoid it being merged into Core prematurely) it is still determining what soft forks are accessible from the signet flag in Bitcoin Core. I don't think it is fair on the signet block signers to put them in that position and I don't think it is wise to put other Bitcoin Core contributors/maintainers in the position of having to defend why some proposed soft forks are accessible on the default signet while others aren't. The default signet was a long term project to address the unreliability and weaknesses of testnet. Many default signet users won't be interested in testing soft fork proposals and it is not reasonable for them to be subject to a stalling or forked blockchain because changes to a soft fork proposal or a buggy soft fork proposal pushed to the default signet makes previous valid/invalid transactions invalid/valid. If they want to test proposed soft forks on a custom signet they are opting in to possible disruption rather than it being forced upon them. By focusing on custom signets rather than the default signet it also allows for more experimentation. Don't like the choices of which soft fork proposals have been added to bitcoin-inquisition? Set up your own custom signet with a different set of soft fork proposals and get users for your custom signet on a level playing field to bitcoin-inquisition. A soft fork proposal is found to be strictly inferior to another soft fork proposal? Just spin down the custom signet with that inferior soft fork proposal on it without impacting default signet users. So TL;DR still enthusiastic about this concept. Just with a strong preference that it is done on a custom signet rather than on the default signet. Thanks Michael -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Monday, September 19th, 2022 at 11:05, Anthony Towns via bitcoin-dev wrote: > On Sun, Sep 18, 2022 at 02:47:38PM -0400, Antoine Riard via bitcoin-dev wrote: > > > Said succinctly, in the genesis of creative ideas, evaluation doesn't > > happen at a single clear point but all along the idea lifetime, where this > > evaluation is as much done by the original author than its peers and a > > wider audience. > > > Sure. I definitely didn't mean to imply a waterfall development model, > or that the phases wouldn't overlap etc. > > > I would still expose a concern to not downgrade in the pure empiricism in > > matter of consensus upgrades. I.e, slowly emerging the norm of a working > > prototype running on bitcoin-inquisition` as a determining factor of the > > soundness of a proposal. E.g with "upgrading lightning to support eltoo", a > > running e2e won't save us to think the thousands variants of pinnings, the > > game-theory soundness of a eltoo as mechanism in face of congestions, the > > evolvability of APO with more known upgrades proposals or the > > implementation complexity of a fully fleshed-out state machine and more > > questions. > > > I agree here; but I think not doing prototypes also hinders thinking > about all the thousands of details in a fork. It's easy to handwave > details away when describing things on a whiteboard; and only realise > they're trickier than you thought when you go to implement things. > > > E,g if one implements the "weird" ideas > > about changes in the block reward issuance schedule discussed during the > > summer, another one might not want "noise" interferences with new > > fee-bumping primitives as the miner incentives are modified. > > > (I don't think "miner incentives" are really something that can be > investigated on signet. You can assume how miners will respond to > incentives and program the mining software to act that way; but there's > no competitive pressure in signet mining so I don't think that really > demonstrates anything very much. Likewise, there's much less demand for > blockspace on signet than on mainnet, so it's probably hard to experiment > with "fee incentives" too) > > > I hope the upcoming > > Contracting Primitives WG w
Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
Hi alicexbt > Good to see some positivity, finally. I had enthusiasm for this concept of enabling proposed soft fork functionality on signet 2 years ago [0]. Nothing has changed, still enthusiastic :) Not enthusiastic about the months wasted on unnecessary contentious soft fork drama since but can't change the past. > 1)Nobody uses Liquid. Signet has more activity than Liquid. 2)Testing something on Liquid will be completely different as its a separate blockchain with some similarities. Perhaps you should take your own advice with regards to positivity (or at least have more of an open mind) with regards Liquid and sidechains. Signet Bitcoin are totally free [1] and experimentation doesn't ever result in loss of real monetary value so you would expect more experimentation on signet versus Liquid long term. However, building protocols and prototypes with real monetary value is a step up from doing so with worthless signet coins. So I don't really see them as direct competitors. Some things take a lot longer to come to fruition than others but the original vision [2] of sidechains still makes perfect sense to me. Competing sets of consensus rules aren't possible on a single mainnet blockchain. Hence you either go the sidechain(-like) route or you go the altcoin route if you want to take the step up from signet/testnet and start using real monetary value. I much prefer the sidechain model to the altcoin route myself. Especially when in say vaults you do want the equiva lent of Bitcoin to be locked up rather than a more volatile altcoin. Thanks Michael [0]: https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-signet-with-multiple-proposed-soft-forks-whilst-maintaining [1]: https://signetfaucet.com/ [2]: https://blockstream.com/sidechains.pdf -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Sunday, September 18th, 2022 at 13:27, alicexbt wrote: > Hi Michael, > > > I agree with Matt. The less said about the "Aw shucks Jeremy didn't know > > that CTV didn't have community consensus at the time" 0 and "it was the > > lack of process that was the problem" the better. > > > The linked gist cannot be taken seriously and I am not sure why you keep > sharing it as some document to prove there was no technical consensus for BIP > 119. Nadav has already mentioned this in the comments. If you care about > community consensus, maybe feedback about the links in that gist should also > be respected. There was chaos, misinformation and lot of drama on twitter. > Some people that opposed CTV on twitter still have no clue what CTV actually > does and a few were super enthusiastic because of the author for BIP 119. > > > I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpaint, > > let's park that for the moment) but I do like the idea of signet having > > soft fork proposals enabled on it 1 whether that be CTV, APO etc and if > > that requires more of the signet code to be moved out of the Core repo so > > be it. > > > Good to see some positivity, finally. Because tx introspection aka covenants > would help everyone involved in bitcoin. This idea of experimenting with soft > forks on signet together with research and meetings suggested by Antoine > should help in better evaluation phase with less drama, politics etc. and > more technical discussions to reach a goal. > > > I'm surprised more isn't being done on Liquid already with what possible > > future functionality is (and could be) enabled 2 there but maybe there is > > more happening than I'm aware of. > > > 1)Nobody uses Liquid. Signet has more activity than Liquid. > 2)Testing something on Liquid will be completely different as its a separate > blockchain with some similarities. > > I have summarized a few other positives of testing soft forks on signet based > on AJ's email: > > a)Better evaluation > b)PR implementing soft fork could be reviewed and merged outside core > c)Testing on signet with pre-existing signet infrastructure > d)Can deploy multiple consensus changes so easier to compare alternative > approaches (eg CTV vs ANYPREVOUT vs OP_TXHASH vs OP_TX, etc) > e)Pre-baked ability to abandon the soft fork > f)No need to regularly rebase consensus changes against bitcoin core's master > branch > > /dev/fd0 > > Sent with Proton Mail secure email. > > --- Original Message --- > On Saturday, September 17th, 2022 at 3:53 PM, Michael Folkson via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > > > I agree with Ma
Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
I agree with Matt. The less said about the "Aw shucks Jeremy didn't know that CTV didn't have community consensus at the time" [0] and "it was the lack of process that was the problem" the better. If people don't care about lack of community consensus there is no process in a permissionless, open source community that can stop them or direct them down a more patient, productive path (I tried). I think it is a shame because I think (maybe I'm wrong) at least in the technical community there is an understanding that long term Bitcoin is far from finished in exhausting its potential and we do need people who will work on changes that we'll need in the long term. There are a few interesting things in here though. I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the moment) but I do like the idea of signet having soft fork proposals enabled on it [1] whether that be CTV, APO etc and if that requires more of the signet code to be moved out of the Core repo so be it. I'm surprised more isn't being done on Liquid already with what possible future functionality is (and could be) enabled [2] there but maybe there is more happening than I'm aware of. Protocols or use cases built out and demonstrated on signet (and/or Liquid/sidechains) seem an obvious stepping stone to me for convincing the community that it is potentially worth taking the chain split risk for a particular upgrade. It is a long slog to get community consensus on an upgrade (Taproot certainly was a slog) but I think the vast majority of us think Taproot was worth that slog and Bitcoin would be poorer today without it. The Great Consensus Cleanup is an interesting example in that I get Matt doesn't have time to champion it or focus on it with his LDK commitments but I have no idea where it would rank on his long term priority list if he wasn't working on LDK. Similarly I have no idea what people who understand this evolving system much better than I do are thinking with regards to say adding new opcodes, sighash flags versus say waiting on Simplicity and possibly adding new functionality within that potential upgrade. For people like me who are extremely unlikely to propose their own consensus change(s) getting some signal on what to spend time digging into would be useful rather than second guessing what people are thinking. There is a danger that you flirt with perceived public roadmaps when possible authority figures stick their necks out and effectively say "I'm not in charge but in an imaginary world where I was this is my current thinking of the ordering in which we could improve this system long term. But this could change depending on x, y and z and possible upgrades are only ready when they're ready and they have community consensus." There is no way people don't play these exercises in their minds. I do, I just have very few answers :) I personally think APO is in prime position to improve Lightning channel state management with eltoo and if it enables some covenant schemes too that seems like an added bonus. On APO versus waiting for APO like functionality in Simplicity I have no idea. Work on APO/eltoo and Simplicity both seem to be progressing in parallel so the APO versus Simplicity discussion perhaps rests on whether people think certain covenants should only really be enabled once we have the security guarantees of Simplicity [3] (if at all). Antoine's covenant R&D effort [4] seems really promising and I hope the shenanigans from earlier in the year don't put people off from engaging with that. Hopefully we can see more exploration, development and research in covenants (e.g. this excellent research paper "Bitcoin Covenants: Three Ways to Control the Future" [5]) and we can foster a community which has very high standards, is open to new ideas and new research but can avoid these months long resisting chain split fights. I think the discussion would be much more interesting and much more productive if people didn't have to think "If I express a view now it will be used to attack me personally later" or worse "If I express a view now it will be used to justify an upcoming chain split". [0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718 [1]: https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-signet-with-multiple-proposed-soft-forks-whilst-maintaining [2]: https://bitcoin.stackexchange.com/questions/109764/what-opcodes-are-supported-on-liquid-but-not-yet-on-bitcoin [3]: https://bitcoinops.org/en/topics/simplicity/ [4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020912.html [5]: https://arxiv.org/pdf/2006.16714.pdf -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Saturday, September 17th, 2022 at 09:39, Matt Corallo via bitcoin-dev wrote
Re: [bitcoin-dev] Transcript: Online Socratic on MuSig2
Hi Ali > do you or anyone else in the Socratic know of any research to this that's > don't involve a trade-off of theft or online connectivity? Any generation of a signature(s), whether that be single key (e.g. OP_CHECKSIG), multisig with multiple signatures going onchain (e.g. OP_CHECKMULTISIG, OP_CHECKSIGADD) or key aggregation multisig with only a single signature going onchain (e.g. OP_CHECKSIG), requires private key(s) and hence has concerns with regards to security and theft of those private keys. Clearly funds locked behind any kind multisig arrangement is better than no multisig arrangement as otherwise theft of a single private key can result in loss of funds. With regards to connectivity or interactivity key aggregation multisig does increase the interactivity requirements so if you wanted to minimize interactivity requirements you'd probably stick to OP_CHECKMULTISIG, OP_CHECKSIGADD that only requires you to generate a signature and then pass it onto the next signer. > ROAST and Liquid is perhaps the farthest I know of that addresses this > problem, but it's using centralized nodes right now. I was thinking, maybe > these federated nodes can be decentralized into a few of these "lite nodes" > managed by each service wanting a payment, that make a threshold signature > out of many subscribers paying at the same time. I'm not sure what you mean here. In the realm of generating signatures there isn't really a concept of a "lite node". That makes more sense in the realm of verification where you may or may not be doing full verification. In the generating signatures realm you are either contributing to the aggregated signature or generating a standalone signature yourself. If you are not doing either of those and aren't doing some kind of coordination then you are entirely irrelevant to the scheme. In the case of Liquid there is a 11-of-15 threshold signature arrangement where currently 11 signatures go onchain when funds are moved but if Liquid used a key aggregation scheme like FROST only a single signature would need to go onchain. With regards to centralization/decentralization you could increase the 11-of-15 to say a 22-of-30. Or you could have a nested MuSig/FROST scheme behind one of the 11 signers of the 11-of-15. But you can't get around the fact that you are either generating a signature that ultimately contributes to the moving of the funds or you aren't. If you aren't generating a signature then you are just verifying the signature(s) that go onchain like all other full nodes on the network. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Sunday, September 11th, 2022 at 08:43, Ali Sherief wrote: > Hi Michael. > > I read the transcript of the Socratic and I have to say that it is quite > detailed and touches a lot of problems including the well-known theft/offline > problems which also has forms elsewhere such as for passwords. > > My question is, do you or anyone else in the Socratic know of any research to > this that's don't involve a trade-off of theft or online connectivity? > > ROAST and Liquid is perhaps the farthest I know of that addresses this > problem, but it's using centralized nodes right now. I was thinking, maybe > these federated nodes can be decentralized into a few of these "lite nodes" > managed by each service wanting a payment, that make a threshold signature > out of many subscribers paying at the same time. > > - Ali___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Transcript: Online Socratic on MuSig2
Hi We had an online Socratic on August 11th with Tim Ruffing (co-author of MuSig2 draft BIP) and Elizabeth Crites (co-author of research papers on MuSig(2), FROST). It was previously announced here [0] but ended up being rescheduled. The transcript is here [1], the video is here [2] and a reading list collecting together a number of resources on MuSig(2), FROST, ROAST etc is here [3]. We discussed a retrospective look at BIP340, handling x-only public keys in MuSig2 and the proposed TLUV covenant opcode, the history from initially broken MuSig1 through MuSig-DN to MuSig2, how MuSig2 and FROST compare for multisig schemes (i.e. n-of-n), why MuSig2 doesn't use proofs of possession and the current state of the draft MuSig2 BIP. We covered a lot of topics and it was rather long (~2.5 hours) so check out the transcript or video if you are interested in any of the above topics. Many thanks to those who participated. Jonas Nick recently tweeted [4] that the MuSig2 BIP [5] is approaching a stable version 1.0 which should be helpful to those who are interested (or already!) using it in the wild. [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020772.html [1]: https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/ [2]: https://www.youtube.com/watch?v=TpyK_ayKlj0 [3]: https://gist.github.com/michaelfolkson/5bfffa71a93426b57d518b09ebd0998c [4}: https://twitter.com/n1ckler/status/1567168267025874944 [5]: https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] P2P trading replacement transactions
Hi alicexbt What do you mean by "replacement transaction"? Replacing or swapping outputs with a counterparty's? I guess I'm struggling to understand exactly what you are attempting to achieve here with regards to privacy and if this additional protocol complexity is worth it. Recall a 2 (or n) party coinjoin would get you an output where it isn't clear to blockchain observers which output you control and a coinswap [0] would have you taking the coin history of your counterparty. What does this scheme offer with regards to privacy that those don't? This seems to have more complexity too though I maybe misunderstanding something. Thanks Michael [0]: https://bitcoinops.org/en/topics/coinswap/ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Friday, August 5th, 2022 at 15:44, alicexbt via bitcoin-dev wrote: > Hi Bitcoin Developers, > > Does it make sense to trade replacement transactions for privacy? I have > shared basic details to implement this and would love to read opinions about > it or ways to improve it: > > = > alice > = > > tx1: input a (0.01) -> output b1 (0.008) > -> change c1 (0.001) > > tx2: input a (0.01) -> output e2 (0.007) > -> output f2 (0.001) > > = > > bob > = > > tx1: input d (0.011) -> output e1 (0.007) > -> change f1 (0.003) > > tx2: input d (0.011) -> output b2 (0.008) > -> output c2 (0.001) > > = > > carol > = > > - creates an API to manage trades that will use 2 of 3 multisig > - alice and bob create orders for replacement > - either they could be matched automatically using some algorithm or bob > manually accepts the offer > - 2 of 3 multisig is created with Alice, Bob and Carol keys > - bob locks 0.01 BTC in it and shares outputs e2,f2 with alice > - alice signs tx2 and shares tx with bob > - alice locks 0.011 BTC in it and shares outputs b2,c2 with bob > - bob signs tx2 and shares with alice > - both replacement txs can be broadcasted > - funds are released from 2 of 3 multisig with a tx having 3 outputs (one to > pay fee which goes to carol) > > positives: > > - privacy > > negatives: > > - extra fees > - will take some time although everything will be managed by wallet with API > provided by carol > - need to lock bitcoin with same amount as used in tx1 > - amounts could still be used to link txs in some cases- carol and other peer > knows the details > > /dev/fd0 > > Sent with [Proton Mail](https://proton.me/) secure email.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs
Thanks for this Luke. > Since BIP125 is widely implemented, it should not be changed except for > corrections to things which are errors deviating from the original intent. In this example the BIP125/RBF rules implemented in Core are (and always have been) different to the rules as described in BIP125. As far as I know other implementations have also followed how it is implemented in Core rather than as described in BIP125. So we have the BIP125 rules, BIP125/RBF as implemented in Core and future intended changes to how RBF rules are implemented in Core which may or may not also be in a state of flux. I take the view that once those new RBF rules are "finalized" there should be a new BIP but others disagree. > Also note that security should NEVER depend on assumptions of node policies. > Doing so would be a serious security vulnerability, regardless of what actual > network policies are. You regularly state this and of course you're right. I tried to allude that it is far from ideal that L2 security is impacted by default policy rules to any extent in my post. But if it is a matter of fact that default policy rules impact the viability of some L2 protocol attacks today what should one do when setting default policy rules in the dominant implementation on the network? I think you lean towards not factoring that in whatsoever to decisions on default policy rules whereas (perhaps mistakenly) I lean towards factoring that in to default policy rule decisions especially when there don't seem to be many other factors to consider. In the case of Lightning Network I think we both want it to succeed and hopefully in the long term default policy rules will have no impact on its security whatsoever. But today that seems to not be the case. -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Thursday, August 4th, 2022 at 20:35, Luke Dashjr wrote: > Policy is a subjective per-node, not systemic, not enforcable or expectable, > and generally not eligible for standardization. > > The reason BIP125 is an exception, is because it is more than just policy. > It is a way for wallets and nodes to communicate. The wallet is saying "this > is the policy I would like you to apply to potential replacements of these > transactions". Whether the nodes abide this request or not, the purpose and > justification of the BIP is to standardize the communication of it. > > Since BIP125 is widely implemented, it should not be changed except for > corrections to things which are errors deviating from the original intent. > If there is merely a new policy intended to be conveyed, a new BIP should be > written that is distinguishable from BIP125 (perhaps drop the sequence number > by 1 more). However, unless nodes are going to honour both the BIP125-request > policy and a new policy, it might be simpler for them to just not honour > the requested BIP125 policy exactly. > > Also note that security should NEVER depend on assumptions of node policies. > Doing so would be a serious security vulnerability, regardless of what actual > network policies are. It's fine to blame nodes/miners if they single out your > transactions, but if it's just a matter of a general policy your transactions > are failing to meet, that's on the sender/L2 to adapt. > > Luke > > > On Thursday 04 August 2022 14:54:54 Michael Folkson via bitcoin-dev wrote: > > > A short history of RBF and BIP125 > > > > The history of BIP125 is as far as I’m aware this. RBF rules were merged > > into Bitcoin Core in November 2015 0. Following that merge David Harding > > and Peter Todd drafted a BIP (BIP125 1) outlining the RBF rules that had > > been implemented in Bitcoin Core. The rationales for the rules in the BIP > > was a bit lacking (in my opinion) but recall this is 2015 (7 years ago!) > > when L2 protocols were in their infancy. Certainly the research on the > > security of L2 protocols has come a long way since and we have a much > > better idea of some of the possible attacks on L2 protocols that to some > > extent are impacted by policy rules. > > > > In addition it was discovered 2 in May 2021 that the Bitcoin Core > > implementation of the RBF rules had never matched the RBF rules outlined in > > BIP125. Clearly this isn’t ideal but mistakes happen and will continue to > > happen. I certainly do not intend any criticism whatsoever to any of the > > individuals involved. Thankfully this discrepancy doesn’t seem to have > > resulted in any loss of funds or disruption. However, cross checking a > > specification with an implementation presumably led to the discovery and >
[bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs
A short history of RBF and BIP125 The history of BIP125 is as far as I’m aware this. RBF rules were merged into Bitcoin Core in November 2015 [0]. Following that merge David Harding and Peter Todd drafted a BIP (BIP125 [1]) outlining the RBF rules that had been implemented in Bitcoin Core. The rationales for the rules in the BIP was a bit lacking (in my opinion) but recall this is 2015 (7 years ago!) when L2 protocols were in their infancy. Certainly the research on the security of L2 protocols has come a long way since and we have a much better idea of some of the possible attacks on L2 protocols that to some extent are impacted by policy rules. In addition it was discovered [2] in May 2021 that the Bitcoin Core implementation of the RBF rules had never matched the RBF rules outlined in BIP125. Clearly this isn’t ideal but mistakes happen and will continue to happen. I certainly do not intend any criticism whatsoever to any of the individuals involved. Thankfully this discrepancy doesn’t seem to have resulted in any loss of funds or disruption. However, cross checking a specification with an implementation presumably led to the discovery and allowed for a post mortem on why the implementation didn’t match the specification. There seems to be two views on what to do next given that the RBF rules need to be updated. One is to ditch the idea of a specification for RBF rules and just document them in the Core repo instead. The other is to have a new specification for the RBF rules in Core and attempt to correct the mistakes made with BIP125 by having a BIP that does correctly outline the RBF rules implemented in Core and includes detailed rationales for why those RBF rules have been implemented. Should anyone care about where things are documented? Perhaps not but I think if you are a stakeholder in L2 protocol security you should. Suppose in the long term future an attacker exploits a L2 vulnerability that is based on the default policy set by the dominant implementation on the network (Bitcoin Core). Which would you prefer the norm to be? A detailed static, well reviewed BIP standard that lays out the updated RBF rules and the rationales for those new rules that is reviewed outside the Core repo and hence not just by Core reviewers? Or cross checking Bitcoin Core code with non-standardized Core documentation typically reviewed only by Core reviewers? For the same reason the norm for consensus changes is a specification (BIP) and a reference implementation (Bitcoin Core) I think the norm for material step change policy changes should be a specification (BIP) and a reference implementation (Bitcoin Core). Policy is of course less risky than consensus for various reasons including there being no chain split risk if the user changes the default policy of their node. Alternative implementations are free to set entirely different policy rules too. But with L2 protocol security to some extent relying on policy whether we like it or not I think we should aspire to similar standards where possible for policy too. Specifications and implementations The Bitcoin Core review process generally requires Concept ACKs, Approach ACKs and then code review, testing ACKs in that order. The reason for this is even if the code is perfect if it is implementing a concept or an approach that informed reviewers oppose then it doesn’t matter that the code is perfect. Documentation is generally done post merge if at all. For most PRs e.g. refactors this makes sense. There is no point documenting something in advance if it is still under review or may not get merged. For consensus PRs this clearly doesn’t make sense. Many of us have and continue to cross check the Taproot BIPs with the Taproot reference implementation in Bitcoin Core. Having two points of reference released simultaneously is treating consensus changes with the highest possible standards we can. I think we should strive towards the highest possible standards for step change default policy changes in Core too given L2 protocol security is (unfortunately, ideally this wouldn’t be the case) relying on them. What are the new RBF rules replacing the BIP125 rules? The new RBF rules as implemented in Core today are documented here [3] in the Core repo (thanks for the link glozow). To the extent that these are a work in progress or close to final (i.e. intended to be static) I don’t know. The devs who work on policy will have a much better idea on these questions than me. Will the new RBF rules continue to be iterated upon as new research on L2 security comes to light? Will this iteration make it impossible to maintain a static set of rules that the broader ecosystem can get comfortable with? Or is a new static set of RBF rules close to being finalized and there is just an aversion to using BIPs and a specification? Generally, as time passes, the ecosystem grows, layers on top of the base layer get built out I
Re: [bitcoin-dev] On a new community process to specify covenants
Hi Antoine This looks great and I can certainly see progress being made in a number of directions on this. I thought you did a great job with the L2 onchain support workshops and I'm sure you'll do a great job moving this forward. One cautionary word from someone who is probably still feeling the effects of burn out from the activation drama earlier in the year. No process can guarantee community consensus at the end of it especially if some of those who we consider experts in this area only tentatively participate. The personal attacks and ignoring of views counter to those who were pushing an activation attempt really should not be repeated. (Especially if this process is seeking to include those who we consider experts in this area and don't want their participation to be perceived as tacit approval of whatever is attempted next.) As long as this is understood and agreed by participants I can only see positives coming out of this. But please let's not repeat the activation drama from earlier in the year because a process with a subset of those who we would consider experts in this area come to a view and then try to ram that view down everyone's throats by attempting activation at the end of it. Maybe this will result in community consensus on covenant proposal(s) going forward but also maybe it won't. Either outcome is fine. At the very least research will progress and work will be carried out that moves us in a positive direction. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Wednesday, July 20th, 2022 at 21:42, Antoine Riard via bitcoin-dev wrote: > Hi, > > Discussions on covenants have been prolific and intense on this mailing list > and within the wider Bitcoin technical circles, I believe however without > succeeding to reach consensus on any new set of contracting primitives > satisfying the requirements of known covenant-enabled use-cases. I think > that's a fact to deplore as covenants would not only offer vast extensions of > the capabilities of Bitcoin as a system, i.e enabling new types of > multi-party contract protocols. But also empowering Bitcoin on its > fundamental value propositions of store of value (e.g by making vaults more > flexible) and payment system (e.g by making realistic channel > factories/payment pools). > > If we retain as a covenant definition, a spending constraint restricting the > transaction to which the spent UTXO can be spent, and enabling to program > contracts/protocols at the transaction-level instead of the script-level, the > list of Script primitives proposed during the last years has grown large : > ANYPREVOUT [0], CHECKSIGFROMSTACK [1], CHECK_TEMPLATE_VERIFY [2], > TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4], PUSHTXDATA [5], CAT [6], EVICT > [7], Grafroot delegation [8], SIGHASH_GROUP [9], MERKLEBRANCHVERIFY [10] and > more than I can't remember. Of course, all the listed primitives are at > different states of formalization, some already fully fleshed-out in BIPs, > other still ideas on whiteboard, yet they all extend the range of workable > multi-party contract protocols. > > Indeed this range has grown wild. Without aiming to be exhaustive (I'm > certainly missing some interesting proposals lost in the abyss of > bitcointalk.org), we can mention the following use-cases: multi-party > stateful contracts [11], congestion trees [12], payment pools [13], "eltoo" > layered commitments [14], programmable vaults [15], multi-events contracts > [16], blockchain-as-oracle bets [17], spacechains [18], trustless collateral > lending [19], ... > > Minding all those facts, I would say the task of technical evaluation of any > covenant proposal sounds at least two fold. There is first reasoning about > the enabled protocols on a range of criterias such as scalability, > efficiency, simplicity, extensibility, robustness, data confidentiality, etc. > Asking questions like what are the interactions between layers, if any ? Or > how robust is the protocol, not just interactivity failure between > participant nodes but in the face of mempools spikes or internet disruption ? > Or if the performance is still acceptable on shared resources like blockspace > or routing tables if everyone is using this protocol ? Or if the protocol > minimizes regulatory attack surface or centralization vectors ? > > Though once this step is achieved, there is still more reasoning work to > evaluate how good a fit is a proposed Script primitive, the > efficiency/simplicity/ease to use trade-offs, but also if there are no > functionality overlap or hard constraints on the use-cases design themselves > or evolvability w.rt future Script extensions or generalization of the opcode > operations. > > Moreover, if you would like your evaluation of a covenant proposal to be
[bitcoin-dev] Online Socratic on MuSig2 and biweekly secp256k1 IRC meeting
Hi There is an online Socratic discussion [0] on MuSig2 next week (Thursday July 28th, 17:00 UTC) that Tim Ruffing has kindly agreed to attend. There is a reading list [1] covering Tim's work and other people's work implementing and researching MuSig2 and hopefully some of those people will attend too. It will be similar in format to the excellent Sydney Socratic with Jesse Posner on FROST in March [2]. For those who prefer IRC discussions rather than video discussions a biweekly secp256k1 IRC meeting (next one is Monday August 1st 2022 at 15:00 UTC) has recently started on the Libera IRC channel #secp256k1. (To be clear this isn't organized by me but I thought it might be of interest to a similar group of people.) Thanks Michael [0]: https://www.meetup.com/bitdevsldn/events/286583988/ [1]: https://gist.github.com/michaelfolkson/5bfffa71a93426b57d518b09ebd0998c [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020352.html -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures
So this half aggregation BIP draft could potentially play the role that BIP340 did for BIP341/342 but it is too premature to start formalizing what the equivalent of BIP341/342 for this draft BIP would look like. And given there are use cases for this half aggregation BIP that can be worked on today (e.g. Lightning gossip [0], Lightning gossip seems to be a very interesting research area at the moment with a number of possible upgrades) it makes sense to focus on those first. There is a section[1] in the CISA repo which I missed originally that describes some of the challenges of implementing CISA/CISHA as a consensus change. A couple of things that stand out to me if this was attempted in the long term. One is that there would almost need to be two tiers of verification: verification for single signature key path spends where CISA, CISHA could be applied and verification for Taproot script paths where CISA, CISHA couldn't be applied. It could even be the case that a new output type is defined specifically for the CISA, CISHA use case where there is no access to a script path at all (i.e. where users don't have a need for anything other than a single signature spend path). With SegWit v0 (and today with SegWit v1) the intention is to get the entire community to move to the new output type. But there could be a long term future where you pick an output type depending on your use case. I recall that Mimblewimble only worked if scripting was ditched entirely and every spend was assumed to be a single signature spend. Anyway...thanks for indulging me on the long term stuff :) [0]: https://github.com/ElementsProject/cross-input-aggregation#sigagg-case-study-ln-channel-announcements [1]: https://github.com/ElementsProject/cross-input-aggregation#integration-into-the-bitcoin-protocol -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Sunday, July 17th, 2022 at 21:45, Jonas Nick wrote: > To be clear, whether "half aggregation needs a new output type or not" does > not > become clear in the draft BIP because it is out of scope. Half-aggregation > has a > few possible applications. The draft only specifies the cryptographic scheme. > > The StackExchange post you link to argues that CISA requires a new output > type. > The same argument applies to half aggregating signatures across transaction > inputs (CISHA, if you will). The only difference to "full aggregation" is that > the transaction signature is a single half-aggregate signature instead of a > 64-byte signature. You're right that it's possible to do batch verification of > Taproot output key spends (Schnorr signatures) and script spends (key tweaks). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures
Thanks for this Jonas. One question that was asked on Telegram (credit: Antoine
D) and isn't clear to me skimming the blog post and the draft BIP is whether
half aggregation needs a new output type or not like we expect cross input
signature aggregation (CISA) to [0]. My understanding is Schnorr signature
batch verification (no aggregation of signatures) can be done today but half
aggregation and CISA would need a soft fork and potentially a new output type
in addition.
(I know this work is in its early stages and won't be proposed for a soft fork
anytime soon. A few of us are just trying to get a basic sketch in our heads of
what they require and whether they could be enabled in the same upgrade.)
[0]:
https://bitcoin.stackexchange.com/questions/106240/will-cross-input-signature-aggregation-need-a-new-output-type/
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
--- Original Message ---
On Friday, July 8th, 2022 at 16:53, Jonas Nick via bitcoin-dev
wrote:
> Half-aggregation has been mentioned several times on this list in various
> contexts. To have a solid basis for discussing applications of
> half-aggregation,
> I think it's helpful to have a concrete specification of the scheme and a
> place
> for collecting supplemental information like references to cryptographic
> security proofs. You can find the BIP draft at
>
> https://github.com/ElementsProject/cross-input-aggregation/blob/master/half-aggregation.mediawiki
>
> Similar to BIP-340, this BIP draft specifies only the cryptographic scheme and
> does not prescribe specific applications. It has not received an extensive
> security review yet. Thanks to Elliott Jin and Tim Ruffing for the review so
> far. One new feature that the specified scheme has is "incremental
> aggregation"
> which allows aggregating additional BIP-340 signatures into an existing
> half-aggregate signature.
>
> While BIP-340 has a pseudocode specification and a reference implementation in
> python, this BIP draft has a formal specification written in hacspec [0] and
> auxiliary pseudocode. The formal specification is a mathematically precise
> description of the scheme, which paves the way for computer-aided formal
> proofs.
> Software tools ("proof assistants") allow proving properties about the formal
> specification ("no integer overflow") and apply formal software verification
> ("implementation is behaviorally equivalent to the spec"). I don't have
> concrete
> plans (nor the skillset) to use these techniques. Still, I think this is an
> exciting area to explore because it has the potential to increase the Bitcoin
> ecosystem's robustness significantly and has little downside. Since hacspec's
> syntax is a subset of Rust's syntax, one can use the standard rust toolchain
> to
> compile, execute and test the specification.
>
> You can find a blog post that gives a broader context at
> https://blog.blockstream.com/half-aggregation-of-bip-340-signatures/
>
> [0] https://github.com/hacspec/hacspec
> ___
> 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] Transcript: Carl Dong on libbitcoinkernel
Hi Another transcript that may be of interest to this list. Carl Dong recently did an excellent short video explaining the libbitcoinkernel project in Bitcoin Core. The transcript is here: https://btctranscripts.com/chaincode-labs/2022-04-12-carl-dong-libbitcoinkernel/ As he explains in the video libbitcoinkernel is the latest attempt to extract the consensus engine out of Bitcoin Core. There are many motivations for doing this. Obviously disagreements between the consensus engines of nodes across the network can lead to catastrophic forks. This boundary between what is part of consensus and what is not has occasionally been blurred in the past and for the most security critical part of Bitcoin Core (and Bitcoin generally) this is clearly unacceptable. This is not a criticism of anyone in the past, unravelling Satoshi's spaghetti code and the entanglement between the consensus engine and the rest of the codebase has been a decade long task, requires extreme care and is by no means completed. As well as leading to some consensus bugs in older versions of Bitcoin Core, the leaky consensus abstraction has made it difficult for alternative implementations to be built in other languages and with different RPCs etc without risking falling out of consensus with Bitcoin Core. This is clearly an ambitious long term project but the first PR in the series was recently merged [1] and Carl explains his thinking on the future direction of this project in the video and on the linked issue. [1]: https://github.com/bitcoin/bitcoin/issues/24303 -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] What to do when contentious soft fork activations are attempted
I’ve been in two minds on whether to completely move on to other topics or to formulate some thoughts on the recent attempt to activate a contentious soft fork. In the interests of those of us who have wasted days/weeks/months of our time on this (with no personal upside) and who don’t want to repeat this exercise again I thought I should at least raise the issue for discussion of what should be done differently if this is tried again in future. This could be Jeremy with OP_CTV at a later point (assuming it is still contentious) or anyone who wants to pick up a single opcode that is not yet activated on Bitcoin and try to get miners to signal for it bypassing technical concerns from many developers, bypassing Bitcoin Core and bypassing users. Maybe the whole thing worked as designed. Some users identified what was going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy Song etc brought additional attention to the dangers, a URSF movement started to gain momentum and those attempting a contentious soft fork activation backed off. (Disappointingly Bitcoin Optech didn't cover my previous posts to this mailing list [1], [2], [3] highlighting the dangers many months ago or recent posts. Normally Optech is very high signal.) Alternatively this was the first time a contentious soft fork activation was attempted, we were all woefully unprepared for it and none of us knew what we were doing. I’m unsure on the above. I’d be interested to hear thoughts. What I am sure of is that it is totally unacceptable for one individual to bring the entire Bitcoin network to the brink of a chain split. There has to be a personal cost to that individual dissuading them from trying it again otherwise they’re motivated to try it again every week/month. Perhaps the personal cost that the community is now prepared if that individual tries it again is sufficient. I’m not sure. Obviously Bitcoin is a permissionless network, Bitcoin Core and other open source projects are easily forked and no authority (I’m certainly no authority) can stop things like this happening again. I’ll follow the responses if people have thoughts (I won't be responding to the instigators of this contentious soft fork activation attempt) but other than that I’d like to move on to other things than contentious soft fork activations. Thanks to those who have expressed concerns publicly (too many to name, Bob McElrath was often wording arguments better than I could) and who were willing to engage with the URSF conversation. If an individual can go directly to miners to get soft forks activated bypassing technical concerns from many developers, bypassing Bitcoin Core and bypassing users Bitcoin is fundamentally broken. The reason I still have hope that it isn't is that during a period of general apathy some people were willing to stand up and actively resist it. [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html [3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Miniscript support in hardware wallets/signing devices
Hi Assessing what should be sent to this mailing list is difficult. We don't want to be bombarded with full on company promotional materials obviously but then at the same time only focusing on contentious consensus changes at the expense of everything else just gives a warped view to readers of this list of what is happening in the community and what 99 percent of Bitcoin devs are working on. One example of many is Miniscript. In this excellent blog post [1] by Salvatore Ingala he explains the work he is doing to get Miniscript support in the Ledger hardware wallet (or "signing device" [2], hat tip nvk). Miniscript has been in the works for a number of years now and the first of multiple Miniscript related pull requests was recently merged into the Bitcoin Core wallet [3]. This wasn't included in the recent Bitcoin Core 23.0 release [4] but one would expect it to be included in the next major release (24.0). Salvatore explains that to start enabling Miniscript support in Ledger only requires ~20 lines of code but there is additional complexity that isn't covered by the included code snippet. And of course the Policy to Miniscript compiler(s) don't (yet) support Taproot trees of scripts so we are talking primarily Bitcoin scripts pre-Taproot. He also includes a short video of what the Policy/Miniscript user experience might look like on a Ledger Nano. For those who are interested in learning more about Miniscript stickies-v is hosting a Bitcoin Core PR review club on Miniscript on May 18th [5]. Disclaimer: I have personal views on hardware wallets/signing devices as anyone does but I do not receive funding from any particular company or product in the space. [1]: https://blog.ledger.com/miniscript-is-coming/ [2]: https://signingdevice.com/ [3]: https://github.com/bitcoin/bitcoin/pull/24147 [4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020321.html [5]: https://bitcoincore.reviews/24148 -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Transcript: Sydney Socratic on FROST w/ Jesse Posner
Hi I thought this transcript might be of interest to the mailing list. https://btctranscripts.com/sydney-bitcoin-meetup/2022-03-29-socratic-seminar/ Jesse Posner joined the online Sydney Socratic [1] last month to discuss his work on FROST. There is a video [2] too. As Jesse states [3] "With the introduction of Taproot, we can begin to bridge this divide between a "hot" and "cold" key by leveraging distributed key generation and threshold signing." During the Socratic he discussed how with FROST you can simulate a threshold signature arrangement (k-of-n, khttps://github.com/bitcoin-sydney/socratic [2]: https://rumble.com/vz3i3u-frost-the-future-of-schnorr-multisignatures-on-bitcoin.html [3]: https://brink.dev/blog/2021/04/15/frost/ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What to expect in the next few weeks
Jeremy > The reason there was not a mailing list post is because that's not a > committed plan, it was offered up for discussion to a public working group > for feedback as a potential plan. In the interests of posterity from your personal blog on April 17th [1]: "Within a week from today, you’ll find software builds for a CTV Bitcoin Client for all platforms linked here: - Mac OSX TODO: - Windows TODO: - Linux TODO: These will be built using GUIX, which are reproducible for verification." Doesn't sound to me that this was being "offered up for discussion". A week from April 17th would have been Sunday April 24th (2 days ago). Readers of this mailing list would have had no idea of these plans. > You've inaccurately informed the list on something no one has communicated committed intent for. I'll let readers assess from the above who is accurately informing the mailing list and who is using personal blog posts and messaging apps to give a completely different impression to one set of people versus readers of this mailing list. I like to give people the benefit of the doubt and assume incompetence rather than malice but when it comes to potential chain splits it doesn't really matter which it is. It has the same effect and poses the same network risk. If and when you try something like this again I hope this is remembered. The Binance hack rollback suggestion, the NACKing then coin flip suggestion on Taproot activation and now this. It seems like this trillion dollar industry is a joke to you. I know we aren't supposed to get personal on this mailing list but honestly if you are going to continue with these stunts I'd rather you do them on a different blockchain. [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Tuesday, April 26th, 2022 at 6:48 AM, Jeremy Rubin wrote: > The reason there was not a mailing list post is because that's not a > committed plan, it was offered up for discussion to a public working group > for feedback as a potential plan. You've inaccurately informed the list on > something no one has communicated committed intent for. This was an > alternative discussed in the telegram messaging app but did not seem to > strike the correct balance so was not furthered. > > I was hoping to be able to share something back to this list sooner rather > than later, but I have not been able to get, among those interested to > discuss in that venue, coherence on a best next step. I communicated inasmuch > on the bird app https://twitter.com/JeremyRubin/status/1518347793903017984 > https://twitter.com/JeremyRubin/status/1518477022439247872, but do not have a > clear next step and am pouring over all the fantastic feedback I received so > far. > > Further, you're representing the state of affairs as if there's a great need > to scramble to generate software for this, whereas there already are scripts > to support a URSF that work with the source code I pointed to from my blog. > This approach is a decent one, even though it requires two things, because it > is simple. I think it's important that people keep this in mind because that > is not a joke, the intention was that the correct set of check and balance > tools were made available. I'd be eager to learn what, specifically, you > think the advantages are of a separate binary release rather than a binary + > script that can handle both cases? I'm asking sincerely because I would make > the modifications to the release I prepared to support that as well, if they > do not entail substantial technical risk. Personally, were I aligned with > your preferences, I'd be testing the forkd script and making sure it is easy > to use as the simplest and most effective way to achieve your ends. > > regards, > > Jeremy > > -- > [@JeremyRubin](https://twitter.com/JeremyRubin) > > On Mon, Apr 25, 2022 at 3:44 PM Michael Folkson via bitcoin-dev > wrote: > >> The latest I'm hearing (this mailing list appears to be being bypassed in >> favor of personal blogs and messaging apps) is that Speedy Trial miner >> signaling for the contentious CTV soft fork is no longer going to start on >> May 5th (as previously communicated [1]) and may instead now start around >> August 1st 2022. >> >> Hence for now the drama seems to have been averted. I am deeply skeptical >> that in the next 3 months this soft fork activation attempt will obtain >> community consensus and will no longer be contentious (although I guess >> theore
Re: [bitcoin-dev] What to expect in the next few weeks
The latest I'm hearing (this mailing list appears to be being bypassed in favor of personal blogs and messaging apps) is that Speedy Trial miner signaling for the contentious CTV soft fork is no longer going to start on May 5th (as previously communicated [1]) and may instead now start around August 1st 2022. Hence for now the drama seems to have been averted. I am deeply skeptical that in the next 3 months this soft fork activation attempt will obtain community consensus and will no longer be contentious (although I guess theoretically it is possible). As a result I suspect we'll be in the exact same situation with a URSF effort required 2-3 months down the line. If we are I'll try to keep the mailing list informed. It is important there is transparency and ample time to research and prepare before making decisions on what software to run. Obviously I have no control over what others choose to do. Please don't be rushed into running things you don't understand the implications of and please only signal for a soft fork if you are convinced it has community consensus (what should precede signaling as it did for Taproot) and you are ready to activate a soft fork. [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Saturday, April 23rd, 2022 at 11:03 AM, Michael Folkson via bitcoin-dev wrote: > As I said in my post: > > "If you care about Bitcoin's consensus rules I'd request you pay attention so > you can make an informed view on what to run and what to support." > > Ideally everyone would come to an informed view independently. Unfortunately > many people don't have the time to follow Bitcoin drama 24/7 and hence > struggle to separate noise from signal. In this case simple heuristics are > better than nothing. One heuristic is to listen to those in the past who > showed good judgment and didn't seek to misinform. Of course it is an > imperfect heuristic. Ideally the community would be given sufficient time to > come to an informed view independently on what software to run and not be > rushed into making decisions. But it appears they are not being afforded that > luxury. > >> I fear you risk losing respect in the community > > I appreciate your concern. > > -- > Michael Folkson > Email: michaelfolkson at [protonmail.com](http://protonmail.com/) > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > --- Original Message --- > On Saturday, April 23rd, 2022 at 6:10 AM, Billy Tetrud > wrote: > >>> assuming people pay attention and listen to the individuals who were >>> trusted during that period >> >> Bitcoin is not run by a group of authorities of olde. By asking people to >> trust "those.. around in 2015-2017" you're asking people to blindly trust >> authorities. This, in my strong opinion, goes against the bitcoin ethos, and >> is an incredibly harmful way to push for your agenda. I'd very much >> recommend you reassess the way you're going about what you're trying to do. >> I fear you risk losing respect in the community by implying without any >> evidence that certain people are "taking advantage" of some situation and >> attempting "to confuse". >> >> On Fri, Apr 22, 2022 at 12:33 PM Michael Folkson via bitcoin-dev >> wrote: >> >>> If the next few weeks go how I fear they will it could get messy. If you >>> care about Bitcoin's consensus rules I'd request you pay attention so you >>> can make an informed view on what to run and what to support. For those of >>> you who were around in 2015-2017 you'll know what to expect. The right >>> outcome endured in 2017 and I'm sure the right outcome will endure here >>> assuming people pay attention and listen to the individuals who were >>> trusted during that period. There are always a large number of motivated >>> parties who are incentivized to break nodes off from Bitcoin and may seek >>> to take advantage of a contentious soft fork activation attempt. >>> >>> Remember that if all the information is presented to users in a clear way >>> well ahead of time then they can make their own mind up. I fear that things >>> will be made as convoluted as possible in a way intended to confuse and >>> information will be withheld until the last minute. When in doubt it is >>> generally better to rely on the status quo and tried and
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Hi Jorge > Can we agree now that resisting a bip8 proposal is simpler and cleaner than > resisting a speedy trial proposal? Personally I'd rather stick to one challenge at a time :) Currently we are facing a contentious soft fork activation attempt of CTV using an alternative client which we expect [1] to be a Speedy Trial deployment. Once this is resolved we can discuss the lessons and observations that come out of this. > Is there any PR to actively resist the proposal on bitcoin core? Not currently. Unless this becomes really, really messy and starts to pose a true existential threat to Bitcoin itself I think it best that attempts to actively resist the proposal are done outside of Bitcoin Core in an alternative client(s). Contrary to what some CTV proponents say getting anything consensus related into Bitcoin Core is extremely difficult (especially at short notice). There is no BDFL or Linus Torvalds like figure, there are a large number of contributors (and maintainers) who all have differing personal views. Hence directing people to have this discussion on a particular PR in the Bitcoin Core repo seems to me to be counterproductive and a massive distraction to other work that is going on on Bitcoin Core. We've already started to see online attacks on Bitcoin Core by CTV proponents [2] claiming an "old guard trying to assert dictatorship over the Bitcoin protocol". It is nonsense of course but directing that nonsense to the Bitcoin Core repo is surely not the right way to go. As I've said in previous emails there is a Libera (and Freenode now) IRC channel ##ursf that has been set up to discuss an alternative client. We'll get a conversation log up too. And of course we wait for confirmation on what the Speedy Trial deployment parameters for this attempted CTV soft fork are going to be. [1]: https://blog.bitmex.com/op_ctv-summer-softfork-shenanigans/ [2]: https://twitter.com/ProofOfKeags/status/1517574210691887105?s=20&t=_jgRh3kkYP3kn1qLuzGXrQ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Saturday, April 23rd, 2022 at 21:40, Jorge Timón wrote: > I've been calling them "controversial softforks" for long. > I hate to be right some times, but I guess I'm happy that I'm not the only > one who distrusts jeremy rubin anymore. > > Can we agree now that resisting a bip8 proposal is simpler and cleaner than > resisting a speedy trial proposal? > I guess now we don't need to discuss it in hypothetical terms anymore, do we? > > Is there any PR to actively resist the proposal on bitcoin core? > > On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev > wrote: > >> Ok so we've had to scramble a bit as I don't think anyone except perhaps >> Jeremy thought that there would be a Speedy Trial signaling period for a CTV >> soft fork planned to start on May 5th [1]. That is two weeks away. >> >> (I have to take what he says at face value. I can understand why one would >> be skeptical.) >> >> Understandably this has angered and surprised a few people including some of >> those who have voiced opposition to a CTV soft fork activation being >> attempted in the first place [2]. >> >> As I've said in a previous post [3] the Bitcoin Core 23.0 release candidate >> (and older versions) does not include any CTV code or CTV activation code. >> If a miner runs Bitcoin Core 23.0 out the box it will not signal for CTV. If >> by some chance CTV was to activate through some other software release >> Bitcoin Core releases would not apply CTV rules but they also wouldn't >> reject blocks that apply CTV rules. Hence it is prudent to prepare for an >> eventuality where the miner signaling threshold might be reached but the >> community wants to prevent the attempted soft fork from activating. (I >> personally don't think a 90 percent miner signaling threshold will be >> reached but I wouldn't want to bet Bitcoin's future on it.) >> >> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but >> I'm open to better names. I certainly don't want to discourage those who >> dislike or oppose UASFs from contributing to this effort and potentially >> ultimately running a URSF release. If you don't want this rushed CTV soft >> fork to activate we are all on the same side whatever we call it. >> >> For now I've set up a ##ursf channel on Libera IRC to monitor developments >> and discuss working on an additional release that if run may ultimately >> reject
Re: [bitcoin-dev] What to expect in the next few weeks
As I said in my post: "If you care about Bitcoin's consensus rules I'd request you pay attention so you can make an informed view on what to run and what to support." Ideally everyone would come to an informed view independently. Unfortunately many people don't have the time to follow Bitcoin drama 24/7 and hence struggle to separate noise from signal. In this case simple heuristics are better than nothing. One heuristic is to listen to those in the past who showed good judgment and didn't seek to misinform. Of course it is an imperfect heuristic. Ideally the community would be given sufficient time to come to an informed view independently on what software to run and not be rushed into making decisions. But it appears they are not being afforded that luxury. > I fear you risk losing respect in the community I appreciate your concern. -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Saturday, April 23rd, 2022 at 6:10 AM, Billy Tetrud wrote: >> assuming people pay attention and listen to the individuals who were >> trusted during that period > > Bitcoin is not run by a group of authorities of olde. By asking people to > trust "those.. around in 2015-2017" you're asking people to blindly trust > authorities. This, in my strong opinion, goes against the bitcoin ethos, and > is an incredibly harmful way to push for your agenda. I'd very much recommend > you reassess the way you're going about what you're trying to do. I fear you > risk losing respect in the community by implying without any evidence that > certain people are "taking advantage" of some situation and attempting "to > confuse". > > On Fri, Apr 22, 2022 at 12:33 PM Michael Folkson via bitcoin-dev > wrote: > >> If the next few weeks go how I fear they will it could get messy. If you >> care about Bitcoin's consensus rules I'd request you pay attention so you >> can make an informed view on what to run and what to support. For those of >> you who were around in 2015-2017 you'll know what to expect. The right >> outcome endured in 2017 and I'm sure the right outcome will endure here >> assuming people pay attention and listen to the individuals who were trusted >> during that period. There are always a large number of motivated parties who >> are incentivized to break nodes off from Bitcoin and may seek to take >> advantage of a contentious soft fork activation attempt. >> >> Remember that if all the information is presented to users in a clear way >> well ahead of time then they can make their own mind up. I fear that things >> will be made as convoluted as possible in a way intended to confuse and >> information will be withheld until the last minute. When in doubt it is >> generally better to rely on the status quo and tried and trusted. In this >> case that would be Bitcoin Core. Alternative releases such as those seeking >> to attempt to activate CTV or indeed those seeking to resist the activation >> of CTV really should only be considered if you are informed on exactly what >> you are running. >> >> If you are interested in the effort to resist the contentious soft fork >> activation attempt of CTV please join ##ursf on Libera IRC. >> >> Have a good weekend. Hopefully those behind this contentious soft fork >> activation attempt will see sense and we can go back to more productive >> things than resisting contentious soft forks. >> >> -- >> Michael Folkson >> Email: michaelfolkson at [protonmail.com](http://protonmail.com/) >> Keybase: michaelfolkson >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 >> >> ___ >> 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] What to expect in the next few weeks
If the next few weeks go how I fear they will it could get messy. If you care about Bitcoin's consensus rules I'd request you pay attention so you can make an informed view on what to run and what to support. For those of you who were around in 2015-2017 you'll know what to expect. The right outcome endured in 2017 and I'm sure the right outcome will endure here assuming people pay attention and listen to the individuals who were trusted during that period. There are always a large number of motivated parties who are incentivized to break nodes off from Bitcoin and may seek to take advantage of a contentious soft fork activation attempt. Remember that if all the information is presented to users in a clear way well ahead of time then they can make their own mind up. I fear that things will be made as convoluted as possible in a way intended to confuse and information will be withheld until the last minute. When in doubt it is generally better to rely on the status quo and tried and trusted. In this case that would be Bitcoin Core. Alternative releases such as those seeking to attempt to activate CTV or indeed those seeking to resist the activation of CTV really should only be considered if you are informed on exactly what you are running. If you are interested in the effort to resist the contentious soft fork activation attempt of CTV please join ##ursf on Libera IRC. Have a good weekend. Hopefully those behind this contentious soft fork activation attempt will see sense and we can go back to more productive things than resisting contentious soft forks. -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
ling >> threshold might be reached but the community wants to prevent the attempted >> soft fork from activating. (I personally don't think a 90 percent miner >> signaling threshold will be reached but I wouldn't want to bet Bitcoin's >> future on it.) > > Making the statement that "the community doesn't want this to activate" as if > it's some kind of foregone conclusion is a pretty bold claim. I think you'll > be surprised at how broad support actually is. To contrast your second > citation, here's the set of people who have endorsed the proposal, along with > a handful of people opposed (such as yourself): https://utxos.org/signals/. > If you are aware of others who are opposed, it would be worth your time to > solicit a statement from them that can be put on the signals page. Absent > that, it seems appropriate to assume that the overwhelming majority of people > who have opined on the subject are for it. >> But as always with Jeremy caution and conservatism seems to be thrown out >> the window and we have to react to that. It goes without saying that this is >> not how Bitcoin consensus changes should be attempted. > > What an unhinged take. The level of effort put into gathering consensus for > CTV has set the bar higher than Taproot. Taproot didn't have the level of > outreach effort that CTV does, and the complexity in taproot is significantly > larger than for CTV. You didn't seem to have a problem organizing that > activation process. That proposal was opened for public discussion in Jan'20, > merged in Oct'20, and you were organizing activation discussions as early as > Jan'21. The design of CTV has been *final* since Feb'20, a month after > Taproot was opened for public discussion. There's a ton of Proof-of-Concept > code that has been written to test out use cases for CTV, but for Taproot it > still doesn't look like we'll have MuSig for a while longer (I heard a year, > but someone can correct me on that if I'm wrong), and wallet support for > Taproot wasn't fleshed out until after activation. Characterizing Jeremy's > efforts as throwing caution and conservatism out the window is hypocritical > at best and malicious at worst. > > Finally, I think it is worth stating that if Bitcoin adopts a culture where a > willfully ignorant set of people can block changes that have no impact on > them, despite a large constituency wanting those changes, then Bitcoin kind > of deserves the slow deterioration that will result from that. I don't really > find that future appealing and so I think that trying to find ways to > activate non-invasive changes should be everyone's goal, *even if* they > personally may not have an immediate use case, or have a slight preference > for alternate solutions. The exception to this is any introduction of > systemic risk. Not all soft-forks are equal, and therefore the meta-consensus > requirements for getting them activated should vary based on how broadly > consequential the change is. > > Feel free to resist this if you want. In some sense that's what the Speedy > Trial procedure is for. However, I think your case would be more compelling > if you actually had some sort of affirmative argument for why CTV induces > systemic risk to non-users of the opcode. Expressing uncertainty over whether > it is the globally optimal solution (to a problem that cannot be globally > defined due to diverse interests) is not persuasive to me and many others in > the community. > Keagan > > On Thu, Apr 21, 2022 at 12:16 PM Michael Folkson via bitcoin-dev > wrote: > >> Ok so we've had to scramble a bit as I don't think anyone except perhaps >> Jeremy thought that there would be a Speedy Trial signaling period for a CTV >> soft fork planned to start on May 5th [1]. That is two weeks away. >> >> (I have to take what he says at face value. I can understand why one would >> be skeptical.) >> >> Understandably this has angered and surprised a few people including some of >> those who have voiced opposition to a CTV soft fork activation being >> attempted in the first place [2]. >> >> As I've said in a previous post [3] the Bitcoin Core 23.0 release candidate >> (and older versions) does not include any CTV code or CTV activation code. >> If a miner runs Bitcoin Core 23.0 out the box it will not signal for CTV. If >> by some chance CTV was to activate through some other software release >> Bitcoin Core releases would not apply CTV rules but they also wouldn't >> reject blocks that apply CTV rules. Hence it is prud
[bitcoin-dev] User Resisted Soft Fork for CTV
Ok so we've had to scramble a bit as I don't think anyone except perhaps Jeremy thought that there would be a Speedy Trial signaling period for a CTV soft fork planned to start on May 5th [1]. That is two weeks away. (I have to take what he says at face value. I can understand why one would be skeptical.) Understandably this has angered and surprised a few people including some of those who have voiced opposition to a CTV soft fork activation being attempted in the first place [2]. As I've said in a previous post [3] the Bitcoin Core 23.0 release candidate (and older versions) does not include any CTV code or CTV activation code. If a miner runs Bitcoin Core 23.0 out the box it will not signal for CTV. If by some chance CTV was to activate through some other software release Bitcoin Core releases would not apply CTV rules but they also wouldn't reject blocks that apply CTV rules. Hence it is prudent to prepare for an eventuality where the miner signaling threshold might be reached but the community wants to prevent the attempted soft fork from activating. (I personally don't think a 90 percent miner signaling threshold will be reached but I wouldn't want to bet Bitcoin's future on it.) I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but I'm open to better names. I certainly don't want to discourage those who dislike or oppose UASFs from contributing to this effort and potentially ultimately running a URSF release. If you don't want this rushed CTV soft fork to activate we are all on the same side whatever we call it. For now I've set up a ##ursf channel on Libera IRC to monitor developments and discuss working on an additional release that if run may ultimately reject blocks that signal for CTV. The intention of this would be to provide additional direction and incentive to miners that the community does not want this soft fork to be activated. To repeat running a Bitcoin Core release will not signal for a CTV soft fork out the box. If a miner runs a Bitcoin Core release it will not signal for CTV. Apologies that this is rushed. But as always with Jeremy caution and conservatism seems to be thrown out the window and we have to react to that. It goes without saying that this is not how Bitcoin consensus changes should be attempted. [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/ [2]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718 [3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] 7 Theses on a next step for BIP-119
Ok last one. Whatever you say and whatever personal attacks you come up with I'm not responding after this one :) > Where can I see the use cases you have built out in recent years? Do you have > a writeup in which you compare CTV to existing covenant enabling proposals? > Do you have a strong reason to favour a different proposal? Have you written > any code? You don't seem to quite understand the asymmetry here. I (and the rest of the community excluding Jeremy) am not a full time CTV developer or full time CTV advocate. There are a number of soft fork proposals I am interested in and attempting to follow in addition to all the work that is going around Taproot etc. But if you/Jeremy want to make a change to the consensus rules the onus is on you to get community review and community consensus. I am not demanding the consensus rules be changed. I am quite happy to wait until there is community consensus over a particular soft fork like there was with Taproot. I have looked into CTV a considerable number of times now. I have asked 5 of the 6 CTV related questions on Bitcoin StackExchange at the time of writing [1], 2 of which I have attempted to answer. Does this mean I understand as much about Jeremy about CTV? Of course not. But if you believe that soft forks should have community consensus it is up to you/Jeremy to address concerns from curious, relatively informed, skeptical people like me. I am not convinced at the time of writing that CTV is the best tool for the job on any of its intended use cases. On this I don't think even Jeremy is convinced as when asked to compare CTV to alternatives he often just says it is ready and other proposals aren't. > In contrast, Jeremy has been doing exactly what you are proposing. He wrote > the BIP, implemented it, explained use cases in detail, spoke at conferences, > organised workshops, and built the Sapio framework for the community to > experiment with covenants. He even puts his money where his mouth is and > offers a bug bounty for any security flaw in the code. I'm not entirely sure where you are going with this. That because Jeremy has worked really hard on it for a long time we should activate it without community consensus? I'm sorry that's not how consensus changes work or how they should work. Personally I very much doubt I will ever attempt to change the consensus rules with one of my proposals. I struggle to follow all of the work and the proposals others work on and at least for now believe others are much more qualified than me to design and code up consensus code changes. So again there is an asymmetry if you are going down the comparing Jeremy's goals with my own. > I think by framing his contributions as "immature" you are disrespecting all > the work he put into BIP-119. I think CTV is an immature proposal given what I've said already about it not being at all clear it is the best tool for any of its intended use cases. > If you are not willing to do what you are suggesting for years why should > anybody else do it? Should the entire community stall progress on covenants > until somebody else works on what you think is ideal? Others are currently working on alternative proposals to CTV (CAT, CSFS, TLUV, Simplicity, arguably APO depending on the use case etc). I haven't asked them to, they already are. As far as I know (they can correct me if wrong) those working on alternative proposals don't support an upcoming activation of CTV. You can try to make this personal all you want and write snide comments if it makes you feel better. But I doubt it is the right approach to getting more review of a soft fork proposal. > Bike shedding is just as big of an issue as "contentious soft forks". > Pointless activation drama is a huge issue of bitcoin protocol development > because it is so draining. Some of the most respected devs do not participate > in activation politics anymore because it harms their health. That's nuts. If > you really want to be of service to the Bitcoin community you should work on > what you think is the right path forward and not just criticise Jeremy for > progressing with his excellent work. If you have a magic wand to wave away activation drama and create an activation method that the entire community is happy with I'd love to see it. That magic wand would have got a few months of my life back in 2021 that I'll never get back. As I said no more responses from me. I am going to go back to a transcript on FROST, one of the many exciting things people are working on that is Taproot related and what I believe the focus should be on at least until there is clear community consensus for a future soft fork. [1]: https://bitcoin.stackexchange.com/questions/tagged/bip119-checktemplateverify -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Origin
Re: [bitcoin-dev] 7 Theses on a next step for BIP-119
covenants at all. It's > not clear to me what you want because you just keep opposing CTV without > trying to make better suggestions. What do you want? > Your other arguments mostly discuss soft forks in general. This is a > different topic though. I think it is not a good idea to mix that up. And > claiming that CTV implies continuous soft forks is again dishonest framing. > It suggests that covenants were just a random idea of Jeremy even though you > know that many reputable bitcoin developers have been researching this topic > for years. Truth is Jeremy does a great service to the community by facing > this draining activation drama to make trustless covenants possible. > > Now, in your most recent email your main concern seems to be a potential > chain split. This is again a weak argument against CTV because your concerns > apply to any upgrade. Furthermore, you are increasing this risk by opposing > CTV without trying to find a common way forward to activate covenants. This > doesn't serve bitcoin. I think it would be better for everyone if you would > invest your time in trying to formulate a better solution. Covenants are too > important to just oppose them because of inaccurate framing or because of > opposition to soft forks in general. > > Regards, > Robin > > [1] https://github.com/JeremyRubin/utxos.org/issues/27 > > --- Original Message --- > On Wednesday, April 20th, 2022 at 3:24 PM, Michael Folkson via bitcoin-dev > wrote: > >>> The client has a Speedy trial release similar to Taproots with parameters >>> proposed to be >> >> As I've said before I was hoping we'd avoid this exercise. Best case, it >> wastes the time of people who could be working on all sorts of valuable >> projects for the ecosystem. Worst case, we take a Russian roulette style >> gamble with a chain split. >> >> But here's a summary of the basic facts: >> >> The latest Bitcoin Core release candidate (23.0) does not contain any new >> soft fork code, either CTV code or any new activation code. Running Bitcoin >> Core 23.0 out the box will not signal for any new soft fork and will not >> enforce any new soft fork rules (CTV or otherwise). Of course it will >> continue to enforce Taproot rules as Taproot activated last year. >> >> There are a number of individuals who have stated opposition to attempting >> to activate a CTV soft fork in the near term: >> >> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718 >> >> Most of those individuals haven't logged their opposition on Jeremy's site: >> https://utxos.org/signals/ >> >> Hence their views haven't been included or discussed in Jeremy's latest blog >> post. >> >> Chain split risk >> >> I can't predict how many full nodes and miners will run Jeremy's client >> attempting to activate CTV. One would expect that many will continue to run >> versions of Bitcoin Core that will not enforce CTV rules and will not >> activate it. But whether Jeremy's client will be a majority, significant >> minority, insignificant minority of full nodes and miners would be >> speculation on my part. (Personally I highly doubt those running Jeremy's >> client will be a majority which leaves a significant minority and >> insignificant minority as the most likely options). >> >> Jeremy's client is intending to use Speedy Trial presumably with similar >> parameters to that used for Taproot. That would mean seeking 90 percent of >> miners to signal for this CTV soft fork activation attempt. >> >> Assuming 90 percent of miners don't signal for it in one of the Speedy Trial >> windows then the activation attempt will have failed and it will be back in >> Jeremy's court whether he tries again with a different activation attempt. >> >> Assuming 90 percent of miners do signal for it (unlikely in my opinion but >> presumably still a possibility) then the CTV soft fork could activate unless >> full nodes resist it. This resistance would most likely be in the form of a >> UASF style client which rejects blocks that apply the CTV rules and/or >> includes transactions that don't meet the CTV rules post activation. We >> would now be in chain split territory with two different assets and >> blockchains like we had with BTC and BCH. >> >> If I oppose this activation attempt and the associated chain split risk what >> should I do? >> >> Firstly, you can register your opposition to this soft fork activation >> attem
Re: [bitcoin-dev] 7 Theses on a next step for BIP-119
> The client has a Speedy trial release similar to Taproots with parameters > proposed to be As I've said before I was hoping we'd avoid this exercise. Best case, it wastes the time of people who could be working on all sorts of valuable projects for the ecosystem. Worst case, we take a Russian roulette style gamble with a chain split. But here's a summary of the basic facts: The latest Bitcoin Core release candidate (23.0) does not contain any new soft fork code, either CTV code or any new activation code. Running Bitcoin Core 23.0 out the box will not signal for any new soft fork and will not enforce any new soft fork rules (CTV or otherwise). Of course it will continue to enforce Taproot rules as Taproot activated last year. There are a number of individuals who have stated opposition to attempting to activate a CTV soft fork in the near term: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718 Most of those individuals haven't logged their opposition on Jeremy's site: https://utxos.org/signals/ Hence their views haven't been included or discussed in Jeremy's latest blog post. Chain split risk I can't predict how many full nodes and miners will run Jeremy's client attempting to activate CTV. One would expect that many will continue to run versions of Bitcoin Core that will not enforce CTV rules and will not activate it. But whether Jeremy's client will be a majority, significant minority, insignificant minority of full nodes and miners would be speculation on my part. (Personally I highly doubt those running Jeremy's client will be a majority which leaves a significant minority and insignificant minority as the most likely options). Jeremy's client is intending to use Speedy Trial presumably with similar parameters to that used for Taproot. That would mean seeking 90 percent of miners to signal for this CTV soft fork activation attempt. Assuming 90 percent of miners don't signal for it in one of the Speedy Trial windows then the activation attempt will have failed and it will be back in Jeremy's court whether he tries again with a different activation attempt. Assuming 90 percent of miners do signal for it (unlikely in my opinion but presumably still a possibility) then the CTV soft fork could activate unless full nodes resist it. This resistance would most likely be in the form of a UASF style client which rejects blocks that apply the CTV rules and/or includes transactions that don't meet the CTV rules post activation. We would now be in chain split territory with two different assets and blockchains like we had with BTC and BCH. If I oppose this activation attempt and the associated chain split risk what should I do? Firstly, you can register your opposition to this soft fork activation attempt on Jeremy's site: https://utxos.org/signals/ It seems Jeremy will continue this activation attempt regardless but it will be useful for others to see clearly that this a contentious soft fork activation attempt and act accordingly. So far only 3 individuals' opposition is registered on his site. Secondly, if it is looking like 90 percent (or whatever percentage Jeremy uses) of miners are going to signal for a CTV soft fork then you can consider joining a UASF style effort to resist the soft fork activation attempt. I will certainly seek to participate and will continue to inform this list of efforts in this direction. The saddest thing is that if Jeremy's soft fork activation attempt causes the uncertainty, confusion and disruption I fear it could it will make future soft forks that do have community consensus orders of magnitude harder to pull off. There are a number of soft fork proposals that I'm personally excited about (enabling covenants, eltoo, Simplicity, CISA etc) that long term we might get with a sensible approach to only activating soft forks that have community consensus. But the more uncertainty, confusion and disruption we create over contentious soft forks the more dangerous any soft fork of any form will appear. The primary focus will need to be resisting soft forks that don't have community consensus and ensuring Bitcoin doesn't splinter into a large number of different assets/blockchains with different combinations of soft forks active. So if you oppose this soft fork activation attempt please voice your opposition, run full node software that doesn't include CTV and CTV activation code such as Bitcoin Core and if/when necessary and available run full node software that proactively rejects application of the CTV rules. -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Tuesday, April 19th, 2022 at 18:31, Jeremy Rubin via bitcoin-dev wrote: > Devs, > > In advance of the CTV meeting today, I wanted to share what my next step is > in advocating for CTV
Re: [bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT)
Hi Jorge > Since this has meetings like taproot, it seems it's going to end up being > added in bitcoin core no matter what. Anyone can set up a IRC channel, anyone can organize a IRC meeting, anyone can announce meetings on the mailing list. Just because an individual is enthusiastic for a soft fork proposal does not imply it has community consensus or that it is likely to be merged into Core in the short term or long term. It is true that other soft fork proposal authors/contributors are not taking the approach Jeremy is taking and are instead working quietly in the background. I prefer the latter approach so soon after Taproot activation but I look forward to hearing about the progress made on other proposals in due course. > Should we start the conversation on how to resist it when that happens? We should talk more about activation mechanisms and how users should be able to actively resist them more. I can only speak for myself but if activation was being pursued for a soft fork that didn't have community consensus I would seek to join you in an effort to resist that activation. Taproot (pre-activation discussion) set a strong precedent in terms of community outreach and patiently building community consensus over many years. If that precedent was thrown out I think we are in danger of creating the chaos that most of us would seek to avoid. You are free to start whatever conversation you want but personally until Jeremy or whoever else embarks on an activation attempt I'd rather forget about activation discussions for a while. > What is ST? If it may be a reason to oppose CTV, why not talk about it more > explicitly so that others can understand the criticisms? ST is short for Speedy Trial, the activation mechanism used for Taproot. I have implored people on many occasions now to not mix discussion of a soft fork proposal with discussion of an activation mechanism. Those discussions can happen in parallel but they are entirely independent topics of discussion. Mixing them is misleading at best and manipulative at worst. > It seems that criticism isn't really that welcomed and is just explained away. Perhaps it is just my subjective perception. Sometimes it feels we're going from "don't trust, verify" to "just trust jeremy rubin", i hope this is really just my subjective perception. Because I think it would be really bad that we started to blindly trust people like that, and specially jeremy. I think we should generally avoid getting personal on this mailing list. However, although I agree that Jeremy has done some things in the past that have been over-exuberant to put it mildly, as long as he listens to community feedback and doesn't try to force through a contentious soft fork earlier than the community is comfortable with I think his work can add material value to the future soft fork discussion. I entirely agree that we can't get into a situation where any one individual can push through a soft fork without getting community consensus and deep technical review from as many qualified people as possible. That can take a long time (the demands on long term contributors' time are vast) and hence anyone without serious levels of patience should probably exclusively work on sidechains, altcoins etc (or non-consensus changes in Bitcoin) rather than Bitcoin consensus changes. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Wednesday, March 9th, 2022 at 11:02 AM, Jorge Timón via bitcoin-dev wrote: > Since this has meetings like taproot, it seems it's going to end up being > added in bitcoin core no matter what. > > Should we start the conversation on how to resist it when that happens? > We should talk more about activation mechanisms and how users should be able > to actively resist them more. > > On Tue, Mar 8, 2022, 03:32 Jeremy Rubin via bitcoin-dev > wrote: > >> * Tuesday, March 8th. >> >> I think Noon PT == 8pm UTC? >> >> but dont trust me i cant even tell what day is what. >> -- >> [@JeremyRubin](https://twitter.com/JeremyRubin) >> >> On Mon, Mar 7, 2022 at 6:50 PM Jeremy Rubin wrote: >> >>> Hi all, >>> >>> There will be a CTV meeting tomorrow at noon PT. Agenda below: >>> >>> 1) Sapio Taproot Support Update / Request for Review (20 Minutes) >>> - Experimental support for Taproot merged on master >>> https://github.com/sapio-lang/sapio >>> 2) Transaction Sponsoring v.s CPFP/RBF (20 Minutes) >>> - >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html >>> - >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html >>> 3) Jamesob's Non-Recursive Vaults Post (20 minutes) >>> - >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020067.html >>> 4) What the heck is everyone talking about on the mailing lis
Re: [bitcoin-dev] [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies
> This is the assumption which I don't agree with and hence asked some > questions in my email. A new RBF policy used by default in Core will not > improve the security of projects that are vulnerable to multiple RBF policies > or rely on these policies in a way that affects their security. Right, not immediately. If and when new policy rules are included in a Bitcoin Core release it would take a while before a significant majority of the network were running those new policy rules (barring some kind of urgency, an attacker exploiting a systemic security flaw etc). That's not an argument not to do it though if you take a longer term perspective on building the strongest possible foundation for Lightning or other Layer 2 projects. The security benefit would just be delayed until a significant majority of Bitcoin Core users upgraded to a version including those new policy rules. > Bitcoin Core with different versions are used at any point and not sure if > this will ever change. Sure there will always be some stray full nodes running extremely old versions but the general direction of travel is more and more full nodes upgrading to newer versions. A network where *all* full nodes are running the same policy rules is clearly not an option available to us without making policy rules effective consensus rules and forking/kicking those old versions off the network. > Maybe some experiments on signet might help in knowing more issues associated > with multiple RBF policies. Definitely agree. It is a really interesting research area and lots of opportunities for simulations and experiments on the default or custom signet networks. Especially if we fill blocks with auto-generated transactions and/or reduce block sizes and create an artificial fee market. -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Monday, February 14th, 2022 at 5:18 AM, Prayank wrote: >> I suspect as with defaults generally most users will run whatever the >> defaults are as they won't care to change them (or even be capable of >> changing them if they are very non-technical). > > 30% nodes are using 0.21.1 right now whereas latest version was 22.0 and some > are even running lower versions. Different versions in future with defaults > might be running RBF v1 and RBF v2. > >> But users who have a stake in the security of Lightning (or other Layer 2 >> projects) will clearly want to run whatever policy rules are beneficial to >> those protocols. > > Agree and attackers will want to run the nodes with policy that helps them > exploit bitcoin projects. Miners can run nodes with policy that helps them > get more fees. > >> As you know the vast majority of the full nodes on the network currently run >> Bitcoin Core. Whether that will change in future and whether this a good >> thing or not is a whole other discussion. But the reality is that with such >> strong dominance there is the option to set defaults that are widely used. > > Bitcoin Core with different versions are used at any point and not sure if > this will ever change. > > https://luke.dashjr.org/programs/bitcoin/files/charts/security.html > > https://www.shodan.io/search/facet.png?query=User-Agent%3A%2FSatoshi%2F+port%3A%228333%22&facet=product > >> I think if certain defaults can bolster the security of Lightning (and >> possibly other Layer 2 projects) at no cost to full node users with no >> interest in those protocols we should discuss what those defaults should be. > > This is the assumption which I don't agree with and hence asked some > questions in my email. A new RBF policy used by default in Core will not > improve the security of projects that are vulnerable to multiple RBF policies > or rely on these policies in a way that affects their security. > > Maybe some experiments on signet might help in knowing more issues associated > with multiple RBF policies. > > -- > Prayank > > A3B1 E430 2298 178F > > Feb 13, 2022, 21:16 by michaelfolk...@protonmail.com: > >> Hi Prayank >> >>> 1.Is Lightning Network and a few other layer 2 projects vulnerable to >>> multiple RBF policies being used? >> >> Clearly the security of the Lightning Network and some other Layer 2 >> projects are at least impacted or partly dependent on policy rules in a way >> that the base blockchain/network isn't. As I (and others) have said on many >> occasions ideally this wouldn't be the case but it is best we can do with >> current designs. I (and others) take the view that this is not a reason to >> abandon those designs in the absence of an alternative that offers a >> strictly superior security model. Going back to a model where *all* activity >> is onchain (or even in less trust minimized protocols than Lightning) >> doesn't seem like the right approach to me. >> >>> 2.With recent discussion to change t
Re: [bitcoin-dev] [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies
Hi Prayank > 1.Is Lightning Network and a few other layer 2 projects vulnerable to > multiple RBF policies being used? Clearly the security of the Lightning Network and some other Layer 2 projects are at least impacted or partly dependent on policy rules in a way that the base blockchain/network isn't. As I (and others) have said on many occasions ideally this wouldn't be the case but it is best we can do with current designs. I (and others) take the view that this is not a reason to abandon those designs in the absence of an alternative that offers a strictly superior security model. Going back to a model where *all* activity is onchain (or even in less trust minimized protocols than Lightning) doesn't seem like the right approach to me. > 2.With recent discussion to change things in default RBF policy used by Core, > will we have multiple versions using different policies? Are users and > especially miners incentivized to use different versions and policies? Do > they have freedom to use different RBF policy? Without making policy rules effective consensus rules users (including miners) are free to run different policy rules. I think it is too early to say what the final incentives will be to run the same or differing policies. Research into Lightning security is still nascent and we have no idea whether alternative Layer 2 projects will thrive and whether they will have the same or conflicting security considerations to Lightning. I suspect as with defaults generally most users will run whatever the defaults are as they won't care to change them (or even be capable of changing them if they are very non-technical). But users who have a stake in the security of Lightning (or other Layer 2 projects) will clearly want to run whatever policy rules are beneficial to those protocols. As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used. I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be. > 3.Are the recent improvements suggested for RBF policy only focused on > Lightning Network and its security which will anyway remain same or become > worse with multiple RBF policies? I think by nature of the Lightning Network being the most widely adopted Layer 2 project most of the focus has been on Lightning security. But contributors to other Layer 2 projects are free to flag and discuss security considerations that aren't Lightning specific. > Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can > readily choose whatever policy *they* want. The maintainer(s) and contributors to Bitcoin Knots are free to determine what default policy rules they want to implement (and make it easier for users to change those defaults) in the absence of those policy rules being made effective consensus rules. I suspect there would be strong opposition to making some policy rules effective consensus rules but we are now venturing again into future speculation and none of us have a crystal ball. Certainly if you take the view that these policy rules should never be made effective consensus rules then the fact there is at least one implementation taking a contrasting approach to Core is a good thing. -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Sunday, February 13th, 2022 at 6:09 AM, Prayank via Lightning-dev wrote: > Hello World, > > There was a discussion about improving fee estimation in Bitcoin Core last > year in which 'instagibbs' mentioned that we cannot consider mempool as an > orderbook in which which everyone is bidding for block space because nodes > can use different relay policies: > https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-22#706294; > > Although I still don't consider fee rates used in last few blocks relevant > for fee estimation, it is possible that we have nodes with different relay > policies. > > Similarly if we have different RBF policies being used by nodes in future, > how would this affect the security of lightning network implementations and > other layer 2 projects? > > Based on the things shared by 'aj' in > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019846.html > it is possible for an attacker to use a different RBF policy with some > nodes, 10% hash power and affect the security of different projects that rely > on default RBF policy in latest Bitcoin Core. > > There was even a CVE in which RBF policy not being documented
Re: [bitcoin-dev] Improving RBF Policy
Thanks for this Bastien (and Gloria for initially posting about this). I sympathetically skimmed the eclair PR (https://github.com/ACINQ/eclair/pull/2113) dealing with replaceable transactions fee bumping. There will continue to be a (hopefully) friendly tug of war on this probably for the rest of Bitcoin's existence. I am sure people like Luke, Prayank etc will (rightfully) continue to raise that Lightning and other second layer protocols shouldn't demand that policy rules be changed if there is a reason (e.g. DoS vector) for those rules on the base network. But if there are rules that have no upside, introduce unnecessary complexity for no reason and make Lightning implementers like Bastien's life miserable attempting to deal with them I really hope we can make progress on removing or simplifying them. This is why I think it is important to understand the rationales for introducing the rules in the first place (and why it is safe to remove them if indeed it is) and being as rigorous as possible on the rationales for introducing additional rules. It sounds like from Gloria's initial post we are still at a brainstorming phase (which is fine) but knowing what we know today I really hope we can learn from the mistakes of the original BIP 125, namely the Core implementation not matching the BIP and the sparse rationales for the rules. As Bastien says this is not criticizing the original BIP 125 authors, 7 years is a long time especially in Bitcoin world and they probably weren't thinking about Bastien sitting down to write an eclair PR in late 2021 (and reviewers of that PR) when they wrote the BIP in 2015. -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Monday, January 31st, 2022 at 3:57 PM, Bastien TEINTURIER via bitcoin-dev wrote: > Hi Gloria, > > Many thanks for raising awareness on these issues and constantly pushing > towards finding a better model. This work will highly improve the > security of any multi-party contract trying to build on top of bitcoin > (because most multi-party contracts will need to have timeout conditions > and participants will need to make some transactions confirm before a > timeout happens - otherwise they may lose funds). > > For starters, let me quickly explain why the current rules are hard to > work with in the context of lightning (but I believe most L2 protocols > will have the same issues). Feel free to skip this part if you are > already convinced. > > ## Motivation > > The biggest pain point is BIP 125 rule 2. > If I need to increase the fees of a time-sensitive transaction because > the feerate has been rising since I broadcast it, I may need to also pay > high fees just to produce a confirmed utxo that I can use. I'm actually > paying a high fee twice instead of once (and needlessly using on-chain > space, our scarcest asset, because we could have avoided that additional > transaction!). > > It also has some annoying "non-determinism". > Imagine that my transaction has been evicted from my mempool because its > feerate was too low. I could think "Great, that means I don't have to > apply BIP 125 restrictions, I can just fund this transaction as if it > were a new one!". But actually I do, because my transaction could still > be in miner's mempools and I have no way of knowing it...this means that > whenever I have broadcast a transaction, I must assume that I will > always need to abide by whatever replacement rules the network applies. > > Fortunately, as far as I understand it, this rule only exists because of > a previous implementation detail of bitcoin core, so there's simply no > good reason to keep it. > > The second biggest pain point is rule 3. It prevents me from efficiently > using my capital while it's unconfirmed. Whenever I'm using a big utxo > to fund a transaction, I will get a big change output, and it would > really be a waste to be unable to use that change output to fund other > transactions. In order to be capital-efficient, I will end up creating > descendant trees for my time-sensitive transactions. But as Gloria > explained, replacing all my children will cost me an absurdly large > amount of fees. So what I'm actually planning to do instead is to RBF > one of the descendants high enough to get the whole tree confirmed. > But if those descendants' timeouts were far in the future, that's a > waste, I paid a lot more fees for them than I should have. I'd like to > just replace my transaction and republish the invalidated children > independently. > > Rule 4 doesn't hurt as much as the two previous ones, I don't have too > much to say about it. > > To be fair to the BIP 125 authors, all of these scenarios were very hard > to forecast at the time this BIP was created. We needed years to build > on those rules to get a better understanding of their limitations and if > th
Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
> Even if we were to adopt something like TXHASH, how long is it going to take > to develop, test, and release? My guess is "a while" - in the meantime, users > of Bitcoin are without a vault strategy that doesn't require either > presigning transactions with ephemeral keys (operationally difficult) or > multisig configurations that would make Rube Goldberg blush (operationally > difficult and precarious). To me this seems to be jumping ahead a number of steps from where we are at the current time. If the ecosystem was widely using all the tools available to them at the current time (MuSig(2), Taproot trees to embed complex scripts, Miniscript etc), was testing out upcoming available tools like threshold key aggregation schemes (e.g. FROST) on signets and the final missing piece was a covenant opcode to avoid the deleted key requirement then the argument for urgency would be stronger. I would still share the concerns I and many others have repeated over rushing soft forks and treating mainnet as a testbed for new use cases rather than the final destination for changes that will stand the test of time. But I would be a lot more sympathetic to that argument. This isn't a criticism of the ecosystem or individual vault projects like Revault, it is clearly still very early. darosior (Revault) is working on getting a first version of Miniscript finalized and in Core [0] and I'm assuming will be part of the effort to get Taproot support in Miniscript assuming that initial effort succeeds. Murch is tracking basic send and receive to the P2TR addresses (not complex scripts, multisig, MuSig(2), merely single key spends) in the ecosystem [1] and there is still a long way to go there. There are a bunch of covenant opcodes that have been enabled on Liquid [2] that I haven't heard yet of anyone building vault prototypes with. It would be good to get others (TLUV, TXHASH) in future. There is not even a custom signet with CTV (as far as I know) for those who subscribe to the view that we must rush to get CTV activated on mainnet as soon as possible with no thought to what opcodes might follow. When this discussion focuses on the pros and cons of various proposals and how they are being tested and used in prototypes on signets, sidechains I think it is really productive. But when it gets onto urgency (or worse activation speculation) I am just perplexed. That viewpoint seems to completely ignore where we are currently with Taproot use and tooling (on which most vault designs will presumably build) and even more perplexingly where we are with vault prototypes on signets, sidechains. I am sure at some point in the future we will have various vault prototypes on signets, sidechains making use of Taproot, Miniscript, MuSig(2), FROST etc and crying out for a covenant opcode or sighash flag to go into production on mainnet. But we seem miles away from that at the present time. [0]: https://github.com/bitcoin/bitcoin/pull/24147 [1]: https://en.bitcoin.it/wiki/Bech32_adoption [2]: https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ‐‐‐ Original Message ‐‐‐ On Friday, January 28th, 2022 at 12:18 AM, James O'Beirne via bitcoin-dev wrote: >> I don't think implementing a CTV opcode that we expect to largely be >> obsoleted by a TXHASH at a later date is yielding good value from a soft >> fork process. > > This presumes the eventual adoption of TXHASH (or something like it). You're > presenting a novel idea that, as far as I know, hasn't had much time to bake > in public. Like Jeremy, I'm concerned by the combinatorial growth of flags > and the implications that has for testing. Caching for something like TXHASH > looks to me like a whole different ballgame relative to CTV, which has a > single kind of hash. > > Even if we were to adopt something like TXHASH, how long is it going to take > to develop, test, and release? My guess is "a while" - in the meantime, users > of Bitcoin are without a vault strategy that doesn't require either > presigning transactions with ephemeral keys (operationally difficult) or > multisig configurations that would make Rube Goldberg blush (operationally > difficult and precarious). The utility of vaulting seems underappreciated > among consensus devs and it's something I'd like to write about soon in a > separate post. > >> The strongest argument I can make in favour of CTV would be something like: >> "We definitely want bare CTV and if we are going to add CTV to legacy script >> (since we cannot use TXHASH in legacy script), then it is actually easier >> not to exclude it from tapscript, even if we plan to add TXHASH to tapscript >> as well." > > Another argument for CTV (which I find especially persuasive) is its > simplicity - it's relativel
[bitcoin-dev] Highlighting Taproot implementation gotchas
Hi I'd just like to bring some attention to this blog post from the Suredbits team who when implementing Taproot in bitcoin-s found a mainnet output that did not conform to the BIP 340 specification [0] (invalid x coordinate) and hence were burned. https://suredbits.com/taproot-funds-burned-on-the-bitcoin-blockchain/ To be clear this is was an error made by an unknown developer rather than a bug in the Taproot BIPs or Core implementation. I'd certainly encourage the community to share with this list mistakes they make or things they find confusing (i.e. stump them for long periods of time) when re-implementing Taproot or supporting Taproot in wallets. I suspect things like eliminating the key path [1] or eliminating the script path [2] will end up being common sources of confusion for wallets. I'm also open to ideas on how there can be greater information sharing so Taproot implementers don't end up making the same mistakes or spending hours confused over the same things. I've heard some feedback on a number of occasions now that the Taproot BIPs although thorough and exhaustive aren't geared directly towards implementers and adopters. We discussed this at an online Socratic last year [3] with Craig Raw an early Taproot adopter with Sparrow Wallet. The transcript of that links to a bunch of existing resources (StackExchange posts, the Optech series "Preparing for Taproot", Optech workshop etc) that may be useful for implementers. wumpus also suggested that a new informational BIP might be a good idea as a first port of call for Taproot implementers who find BIP 340-342 dense and difficult to parse. This is certainly something we can do once it becomes clearer what that informational BIP should contain. Of course the Libera IRC channels #bitcoin-dev (for general Bitcoin development) and #bitcoin-core-dev (for Core related development) are there for discussion and questions. And as many will already know Murch is tracking P2TR support on the Bitcoin wiki [4]. Thanks Michael [0]: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design [1]: https://bitcoin.stackexchange.com/questions/99722/taproot-eliminating-key-path [2]: https://bitcoin.stackexchange.com/questions/99325/how-do-i-construct-a-p2tr-address-if-i-just-want-to-use-the-key-path [3]: https://btctranscripts.com/london-bitcoin-devs/2021-07-20-socratic-seminar-taproot-rollout/ [4]: https://en.bitcoin.it/wiki/Bech32_adoption -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CTV BIP review
Eric, Luke
Can I request that you don't discuss activation methods for future soft forks
on a thread for CTV BIP review? I (and a number of others [0]) do not support
an upcoming activation attempt of standalone OP_CTV. If you want to discuss
activation methods for soft forks generally it would be much better if you set
up a separate thread. OP_CTV is not the only current soft fork proposal and
there will likely be more.
The activation discussion for Taproot was deliberately kept separate from the
review of the Taproot BIPs and implementation. It only commenced once there was
overwhelming community consensus for the soft fork to be activated (months
after in fact). Though you are free to discuss whatever topics you wish
(obviously) discussing soft fork activation methods on a OP_CTV thread might
give the mistaken impression that OP_CTV is the next soft fork to be activated
which is mere speculation at this point. In an ideal world the promoters of
OP_CTV would follow the strong precedent set by the authors and contributors to
the Taproot BIPs but regrettably that seems to have gone out the window at this
point.
Thanks
Michael
[0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
‐‐‐ Original Message ‐‐‐
On Tuesday, January 18th, 2022 at 11:00 PM, Eric Voskuil via bitcoin-dev
wrote:
> -Original Message-
>
> From: Luke Dashjr l...@dashjr.org
>
> Sent: Tuesday, January 18, 2022 2:10 PM
>
> To: e...@voskuil.org
>
> Cc: 'Bitcoin Protocol Discussion' bitcoin-dev@lists.linuxfoundation.org
>
> Subject: Re: [bitcoin-dev] CTV BIP review
>
> On Tuesday 18 January 2022 22:02:24 e...@voskuil.org wrote:
>
> > The only material distinction between BIP9 and BIP8 is that the latter
> >
> > may activate without signaled support of hash power enforcement.
> >
> > As unenforced soft forks are not "backward compatible" they produce a
> >
> > chain split.
>
> Enforcement of the Bitcoin consensus protocol is by users, not miners.
Given that I stated "hash power enforcement" it is quite clear that this is
in fact only produced by mining. You are misrepresenting my statement to
make an emotional appeal. Without "hash power enforcement", a soft fork is
NOT backward compatible.
"[enforcement of] consensus protocol" is of course by merchants, but that is
not the question at hand. The question is explicitly compatibility. Anyone
can activate a soft fork at any time, but without "hash power enforcement"
soft forks are NOT backward compatible.
> Softforks never produce a chain split. Miners can, and might try to do it
to cause disruption in retaliation, but the softfork itself does not.
Maybe you are trying to split hairs given the fact that blocks are produced
only by miners, so only miners can "cause" a split.
But through not intention ("disruption in retaliation") whatsoever by
mining, a soft fork will result in those activating the rule being split off
the original chain unless majority hash power enforces the rule. The fact
that doing nothing apart from deploying the rule will result in a split is
the very definition of NOT compatible.
I assume you will argue that the original chain is not "valid" and therefore
irrelevant (as if no chain split occurred). But again the point is about
compatibility. The appearance of multiple chains, which appear valid
according to either the previous or new rules, is obviously the
incompatibility.
I shouldn't have to point this out, but observed chain splits have occurred
in more the one large scale soft fork deployment. These splits have only
been resolved through hash power enforcement. In 2010 it took 51 blocks
before the current chain took the lead. In 2012 minority chains persisted
for months. The deployment of soft forks caused these splits, NOT the
actions of miners. And unless majority hash power eventually enforces it,
the soft fork branch necessarily dies.
> > It was for this reason alone that BIP8 never gained sufficient
> >
> > support.
>
> BIP 8 in fact achieved consensus for Taproot activation.
Please define "achieved consensus", because by any definition I can imagine,
this is simply untrue.
> > This is one of the most misleading statements I've seen here. It's not
> >
> > technically a lie, because it states what "should" happen. But it is
> >
> > clearly intended to lead people to believe that BIP8 was actually used
> >
> > ("again") - it was not. ST was some technical tweaks to BIP9.
>
> BIP 8 was used to activate Taproot.
No, it wasn't. I find it hard to imaging how you rationalize such grossly
misleading statements.
> > The outright deception around this one topic has led to significant
> >
> > unnecessary conflict in the community. Make your argument, but make it
> >
> > honestly.
>
> You are the one attempting to deceive here.
That is for others
Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
You are working on a use case of OP_CTV now? Cool, you only recently announced you were working on Bitcoin Knots (and I think Wasabi before that) so I'm losing track of all the announcements. Regardless stick with it and build out more than a rudimentary proof of concept. That is one of the things that is severely lacking at this point for OP_CTV. > TBH I am not against Miniscript and still waiting for its support in Core > which might take another few years. I would love to have multiple programming > languages so that application developers can decide what works best for them. I would hope you weren't against Miniscript because Sapio is built on top of it :) But whatever have fun, I can't do this all day. -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ‐‐‐ Original Message ‐‐‐ On Tuesday, January 4th, 2022 at 3:06 PM, Prayank wrote: > What I have done related to OP_CTV? > > https://twitter.com/prayankgahlot/status/1456643891885592579 > > What am I currently working on that is not shared publicly and will do in > next few weeks? > > Review pull request 21702 and write contracts using Sapio based on few ideas > that I already have. > > What is this assessment based on? > > A few months are enough for the recent bounty to find bugs if possible and > other things pending to be completed. > >> you haven't thought about alternative proposals for any particular use case >> (vaults for example have multiple current alternative proposals and most >> likely many future ones) > > I have read enough about alternative proposals and some of them don't even > compete with OP_CTV, they can all be implemented and complement each other. > Vaults is not the only thing that I care about and it would be better if we > don't assume about research done by others. > >> A new programming language (Sapio) sounds great but do you you need it for >> your use case rather than an alternative high level language like Minsc? >> Sapio makes use of Miniscript which hasn't been finalized yet or updated for >> Taproot. Surely that needs to be done first otherwise Sapio is built on top >> of something that isn't ready? When you make the claims such as a consensus >> change is ready to go the burden is on you to convince me and other skeptics >> why. The status quo is the default. "I think it is ready or will be ready" >> doesn't mean much unless you have done the work. > > TBH I am not against Miniscript and still waiting for its support in Core > which might take another few years. I would love to have multiple programming > languages so that application developers can decide what works best for them. > > I don't understand what work are you expecting me to do in this case to share > my opinion about a soft fork. > >> It is not enough for one individual to say it is ready to be activated, >> anyone who is expressing that view should understand why the opcode has been >> designed in the way it has and why it is so important that we should >> dedicate months of community time to getting a single opcode activated this >> year. > > I have dedicated enough time reading everything related to OP_CTV and discuss > things that were posted earlier here by Jeremy Rubin. Not sure how many > skeptics did the same or even tried to discuss anything until recent bounty > was announced. > >> You regularly NACK Core PRs yet you seem willing to wave a consensus change >> through with no outstanding questions and zero skepticism. > > I would NACK and write the reasons in this pull request as well if I find any > issues and PR author is not addressing them. I had lots of questions at > conceptual level which have been answered on different platforms and I cannot > document each conversation. Its a Concept ACK from me and none of the > contributors could find any issues with PR right now so I don't want to stop > people from improving Bitcoin. > >> As I understand there are IRC workshops next week on BIP 119 [1] that I'd >> encourage you to join so you can start getting into a position where you can >> engage with the skeptics on technical concerns. Regrettably (as I said I >> find this work interesting) I don't feel like I can participate because >> deployment and activation is being included and I think it is irresponsible >> to be discussing those at this point. In my view activation should not even >> be speculated upon until it is clear there is overwhelming community support >> for a soft fork being activated. > > I would be attending the workshops and had even requested Jeremy to use > Twitch because it would help more people understand things with audio, screen > sharing etc. I would love to see skeptics participate and discuss technical > things. > >> I don't feel like I can participate because deployment and activation is >> being included and I think it is irresponsible to be discussing those at >>
Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
> It should be ready to go in a few months IMO What is this assessment based on? I am assuming you haven't done a code review of the opcode, you haven't coded up a real world use case of OP_CTV (or even a primitive proof of concept), you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones). A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work. You are well aware of the review process in Core for non-consensus changes. For consensus changes you really should be digging even deeper, the bar should be higher and all questions you and others have should be explored in depth. It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year. I have more sympathy for those who don't follow Bitcoin Core development and Bitcoin Core review on an ongoing basis (note as I said that the bar for consensus changes should be significantly higher than a non-consensus PR). The use cases sound cool and the work is genuinely interesting. But honestly for someone who has followed Bitcoin Core development, review for a while now you really should know better than bandy around statements like "it should be ready to go in a few months" when you currently haven't scratched the surface on the utility and safety of this opcode. You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism. > If I had to select between a soft fork without any use cases and one with use > cases, I would go with the one that has some use cases with code, > documentation etc. You should propose a new opcode but OP_CTV is not claiming > to cure cancer. Multiple proven built out use cases, sure. Multiple is better than single when you have done the work to ensure they are actually the right tool for those multiple use cases. This work hasn't been done on any of these use cases. The curing cancer analogy was used to elucidate the point that claims should be deeply explored rather than just accepted as true. >> To contrast with his approach, the authors and contributors of another >> future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting >> an imminent soft fork activation attempt and instead are building out and >> testing one of the speculated use cases, eltoo payment channels [4]. > Because its not ready? As I said it is not ready because the ANYPREVOUT contributors are building out and testing a use case. The high bar on readiness should be applied to all proposals not merely the ones where the authors/contributors decide to impose a high bar themselves. I don't really want to spend my year imploring people to dig deeper on this before indicating they support an imminent activation attempt. Some people don't have the understanding to dig deeper, some people don't have the time and some don't have either. However, if an activation of OP_CTV is attempted this year I am sure it will be contentious [0]. Anyone who cares about Bitcoin development and the ongoing technical work in a multitude of areas should be strongly against a contentious soft fork activation attempt wasting the time of developers and the entire ecosystem even if they don't have the understanding or time to appreciate the reasons why it is contentious. As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated. [0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718 [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4
[bitcoin-dev] Stumbling into a contentious soft fork activation attempt
I have already expressed my arguments on the regularity of soft forks [0]. Having spent months of my time on Taproot activation last year attempting to get at least rough community consensus on the activation method it seems crazy to me that some want to do that again so soon after Taproot activation and somehow this time it will be plain sailing. (Spoiler: it won’t. Although Taproot safely activated there remain outstanding views ranging on whether BIP 8 or 9 variants of Speedy Trial should be used in future to Speedy Trial only being a short term stopgap that should not be repeated.) If OP_CTV is ready to go now and has overwhelming community support (I don’t think either is true) it should surely have been included in the Taproot soft fork (perhaps delayed) rather than going through the months of activation wrangling and community outreach twice. I stated in that post: “A contentious or disputed soft fork can be merged into a Bitcoin implementation at any time but doing this is opening the door to the schism, disruption and waste of developer hours that we saw in 2017. Personally I think we’ll see an attempt to activate a contentious soft fork at some point in the long term future (Murphy’s Law) but any attempt to do so should be strongly discouraged. It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem. Longer term I have confidence in Bitcoin’s ability to survive whatever happens but allocating significant community resources to resist an unnecessary contentious soft fork (or even regular contentious soft forks) is not an optimal use of those resources.” I am getting increasingly concerned that we are stumbling into this scenario three months after I wrote that post. One of many future soft fork proposals (as many will know) is BIP 119 [1] which is the enabling of a new opcode OP_CHECKTEMPLATEVERIFY (OP_CTV). It seems to me like the author and primary promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted activation of a soft fork containing exclusively OP_CTV [2]. To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4]. Similar work has not been done for any of the speculated use cases of OP_CTV. Instead Jeremy is encouraging people to “soft signal” for soft fork activation of OP_CTV presumably in the hope that the building out and testing of use cases can be completed post activation. This is totally irresponsible in my view. A long list of speculated use cases means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will cure cancer with no potential downsides and hence we should have a soft fork activating it as soon as possible. I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day. It is true that Jeremy has some rudimentary proofs of concept built but as any software engineer will tell you the vast majority of the challenges are encountered once you attempt to build out that proof of concept. Once you do you may realize that the tool (or opcode) you are using isn’t the right one for the job. Unlike adjusting a feature on a social media app adjusting a consensus change once it has been activated is trickier to put it mildly. There are a number of other more interesting technical discussions to be had later (what kind of covenants we want and are able to enable safely on Bitcoin etc, how CTV compares to other covenant enabling proposals, to what extent activating CTV would impact future proposals) but I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt. Jeremy has put up this site (https://utxos.org/signals/) which is collecting so-called “soft signals”. I very much doubt anyone has a problem with Jeremy engaging with the community on his proposal and receiving feedback. However, the site currently states: “The following organizations, individuals, or pools have communicated preference for and intent to support a BIP-119 activation attempt using reasonable parameters. These “soft signals” are non-binding until an actual concrete proposal has been formed, but are useful for measuring community consensus.” There have been a number of “soft signals”, many expressing enthusiasm for the speculated use cases of OP_CTV. Personally I share that enthusiasm like I do with the prospect of curing cancer. But these soft signals seem as if they are going to be used to attempt to justify an imminent contentious soft fork attempt. The devil is in the details both with regards to wording like “reasonable parameters” and the utility and s
[bitcoin-dev] Taproot activates - A time/block line
I thought I would collect together the highlights from Taproot activating for those strange Bitcoin history buffs (including myself). If you’d rather watch in video form 0xB10C provided an excellent livestream [0] showing blocks and transactions in the run up to and directly after Taproot activating. Back in July [1] 0xB10C (with the help of F2Pool) spent from Taproot (P2TR) outputs months before Taproot activated. Taproot rules weren’t being enforced and hence these spends were treated as anyone-can-spend. Hence I won’t treat these as the “first” Taproot spends as they didn’t need to meet Taproot consensus rules. Block 709631: The last block before Taproot rules were enforced was mined by AntPool. By this point there were various P2TR outputs in blocks, some timelocked for higher than block 709631 but others not timelocked. These non-timelocked P2TR outputs were in effect anyone-can-spend like the ones 0xB10C spent from in July as Taproot rules were not yet being enforced. No P2TR outputs were spent immediately before activation as far as I can tell. Block 709632: The first block where full nodes started enforcing Taproot rules was mined by F2Pool. It seems [2] F2Pool wasn’t enforcing Taproot rules and did not include any Taproot spends (some with high fee rates) in this block. More seriously an invalid Taproot spend included in this block could have cost them the block reward and caused a re-org when full nodes (and miners) enforcing Taproot rules rejected this block. Given they didn’t include any attempted Taproot spends (valid or invalid) in the block this protected them from that but it does lead to discussions for a later time on whether Speedy Trial signaling was effective if some mining pools signaled readiness months previous but then did not enforce the new soft fork rules on activation. Block 709633: Mined by AntPool. Similar to F2Pool they didn’t include any Taproot spends in this block and one would assume that they also weren’t enforcing Taproot rules though this has not been confirmed. Block 709634: Also mined by AntPool. Block 709635: The first block which included (numerous) valid Taproot spends (and no invalid Taproot spends) was mined by Foundry USA. The first Taproot spend [3] was completed by bitbug42. It was a key path spend and the OP_RETURN in this first Taproot spend contained the message “I like Schnorr sigs and I cannot lie”. Andrew Chow had the second Taproot spend [4] but the first script path spend. He also spent from two Taproot vanity addresses beginning bc1ptapr00t which were presumably generated using his Rust Bitcoin Vanity Address Generator [5]. Pieter Wuille had the third Taproot spend [6]. He also had the bronze medal for SegWit spends on SegWit activation in 2017 [7], he was third then too. However, his vanity address game stepped up for Taproot. For SegWit he spent from one vanity address beginning 35Segwit. This time he spent from vanity addresses beginning bc1ptapr00tearly, bc1pay2tapr00t, bc1pmyusetapr00t, bc1partytaptap and this isn’t including all the vanity addresses that were sent to. He (with Greg Maxwell’s help) searched 2.4 quadrillion keys in a week [8]. BitGo had the fourth Taproot spend [9] and the first Taproot multisig spend via the script path. The script used OP_CHECKSIG and OP_CHECKSIGVERIFY which have been modified with the Taproot upgrade to check Schnorr signatures but it didn’t use the new opcode OP_CHECKSIGADD that has been introduced for threshold (and multi) signatures. It contained an OP_RETURN message with “Thx Satoshi! ∞/21mil First Taproot multisig spend -BitGo” jaoNoctus claimed the fifth Taproot spend and narcelio and ottosch claimed the sixth and seventh Taproot spends. The first use of OP_CHECKSIGADD on mainnet was completed [10] by Alekos Filini using modified code [11] from the BDK (Bitcoin Dev Kit) library. Any errors are my own and I will gladly correct. Thanks to 0xB10C, Greg Maxwell, Pieter Wuille, Murch, Andrew Chow, BitGo, Daniel McNally, Rearden Code, Alekos Filini, Chun, pinheadmz for highlighting these various events online. Thanks to the various block explorers (Esplora, mempool.space etc) that were very useful for monitoring Taproot activation. And thanks to the community as a whole for participating and engaging with this successful upgrade. Without participation and engagement these upgrades are meaningless and it is a great sign for Bitcoin’s future that there was so much interest and scrutiny of this upgrade. [0]: https://www.youtube.com/watch?v=1jijKVB1cNA, https://www.twitch.tv/0xb10c/video/1204909643 [1]: https://b10c.me/blog/007-spending-p2tr-pre-activation/ [2]: https://twitter.com/satofishi/status/1459868549674065926?s=20 [3]: 33e794d097969002ee05d336686fc03c9e15a597c1b9827669460fac98799036 [4]: 3defed8717c581b4c0509329550e344bdc14ac38f71fc050096887e535c8 [5]: https://github.com/achow101/rust-vanitygen [6]: 83c8e0289fecf93b5a284705396f5a652d9886
Re: [bitcoin-dev] On the regularity of soft forks
> Interesting discussion.Correct me if I'm wrong: but putting too many features > together in one shot just can't make things harder to debug in production if > something very unexpected happens.It's a basic principle of software > engineering. Soft fork features can (and should) obviously be tested thoroughly on testnet, signet, custom signets, sidechains etc on a standalone basis and a bundled basis. But whether or not it is a basic principle of general software engineering kind of misses the point. Security critical software clearly isn't engineered in the same way as a new social media app. Bugs are easily reverted in a new social media app. A consensus change is extremely hard to revert and probably requires a hard fork, a level of central coordination we generally attempt to avoid and a speed of deployment that we also attempt to avoid. On top of that we aren't just dealing with security critical software. One of the most important objectives is to keep all the nodes on the network in consensus. Introducing a consensus change before we are comfortable there is community consensus for it is a massive effective bug in itself. The network can split in multiple ways e.g. part of the network disagrees on whether to activate the consensus change, part of the network disagrees on how to resist that consensus change, part of the network disagrees on how to activate that consensus change etc In addition, a social media app can experiment in production whether Feature A works, whether Feature B works or whether Feature A and B work best together. In Bitcoin if we activate consensus Feature A, later decide we want consensus Feature B but find out that by previously activating Feature A we can't have Feature B (it is now unsafe to activate it) or its design now has to be suboptimal because we have to ensure it can safely work in the presence of Feature A we have made a mistake by activating Feature A in the first place. Decentralized security critical consensus changes are an emerging field in itself and really can't be treated like any other software project. This will become universally understood I'm sure over time. -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ‐‐‐ Original Message ‐‐‐ On Friday, October 15th, 2021 at 1:43 AM, Felipe Micaroni Lalli via bitcoin-dev wrote: > Interesting discussion.Correct me if I'm wrong: but putting too many features > together in one shot just can't make things harder to debug in production if > something very unexpected happens. It's a basic principle of software > engineering. > > Change. Deploy. Nothing bad happened? Change it a little more. Deployment. > > Or:Change, change, change. Deploy. Did something bad happen? What change > caused the problem? > > On Thu, Oct 14, 2021 at 8:53 PM Anthony Towns via bitcoin-dev > wrote: > >> On Mon, Oct 11, 2021 at 12:12:58PM -0700, Jeremy via bitcoin-dev wrote: >>> > ... in this post I will argue against frequent soft forks with a single or >>> minimal >>> > set of features and instead argue for infrequent soft forks with batches >>> > of features. >>> I think this type of development has been discussed in the past and has been >>> rejected. >> >>> AJ: - improvements: changes might not make everyone better off, but we >>> don't want changes to screw anyone over either -- pareto >>> improvements in economics, "first, do no harm", etc. (if we get this >>> right, there's no need to make compromises and bundle multiple >>> flawed proposals so that everyone's an equal mix of happy and >>> miserable) >> >> I don't think your conclusion above matches my opinion, for what it's >> worth. >> >> If you've got two features, A and B, where the game theory is: >> >> If A happens, I'm +100, You're -50 >> If B happens, I'm -50, You're +100 >> >> then even though A+B is +50, +50, then I do think the answer should >> generally be "think harder and come up with better proposals" rather than >> "implement A+B as a bundle that makes us both +50". >> >> _But_ if the two features are more like: >> >> If C happens, I'm +100, You're +/- 0 >> If D happens, I'm +/- 0, You're +100 >> >> then I don't have a problem with bundling them together as a single >> simultaneous activation of both C and D. >> >> Also, you can have situations where things are better together, >> that is: >> >> If E happens, we're both at +100 >> If F happens, we're both at +50 >> If E+F both happen, we're both at +9000 >> >> In general, I think combining proposals when the combination is better >> than the individual proposals were is obviously good; and combining >> related proposals into a single activation can be good if it is easier >> to think about the ideas as a set. >> >> It's only when you'd be rejecting the proposal on its own merits that >> I think combining it with others is a bad idea in principle. >> >> For specific examples, we bundled
[bitcoin-dev] On the regularity of soft forks
I was hoping to delay this post as long as possible because there are so many interesting and important things to discuss other than soft forks and consensus changes that seem to have taken a backseat this year due to Taproot activation. In addition, there seems to be a world of opportunity to leverage the upcoming Taproot soft fork that risks getting drowned out by speculating on the next soft fork. There is clearly nothing wrong with some individuals continuously working on, designing and refining new possible consensus changes and whoever is interested is free to follow and participate in those discussions. This is Bitcoin, no one let alone me can decide what people should focus on. Indeed I intend to allocate a portion of my time to following and understanding the trade-offs of current and future soft fork proposals. However, in this post I will argue against frequent soft forks with a single or minimal set of features and instead argue for infrequent soft forks with batches of features. I fully understand the desire and motivation to get consensus changes into Bitcoin as quickly as possible when certain use cases depend on them. However, the robustness, security and ability to resist harmful or suboptimal changes to the system is clearly the ultimate priority. The more frequently soft forks are attempted the harder it is for the community to ensure harmful or suboptimal changes don’t creep into the consensus rules. I am well aware of how much community mindshare Taproot activation demanded this year. This is how it should be. The community should be informed and vigilant when the consensus rules are changed. Every full node will either immediately on activation or in future enforce these consensus rule changes and so it is in the interests of every full node operator that these changes have been subject to the ultimate levels of community review and rigorous testing. Attempting them frequently either requires continuous community monitoring or an acceptance that an unneeded or harmful consensus change could easily creep into Bitcoin. Neither of these options seem acceptable to me. It is not reasonable to ask all the different segments of the community to dedicate full time resources to stay on top of proposed consensus changes. Hence treating a pull request to a Bitcoin implementation that requires a soft fork like any other pull request is shortsighted. Merging soft fork code into a Bitcoin implementation The code for a soft fork should not be merged into a Bitcoin implementation, let alone activation parameters (discussed later), until the maintainers of that implementation are comfortable that the entirety of that soft fork has sufficient community consensus. This includes what many consider the reference implementation and dominant implementation on the network, Bitcoin Core. A soft fork pull request cannot and should not be treated like any other pull request which can be merged with anything from 1 to 10 ACKs from long term or newer contributors. The act of merging a pull request that is part of a proposed soft fork is an acknowledgement by the maintainer(s) of that implementation that they consider the entirety of that proposed soft fork to have community consensus. That includes what is included in that soft fork as well as what isn’t. If there is a prevailing view that the current design could be improved, could feasibly be replaced by something superior in future or merely hasn’t been subject to sufficient community review it should not be merged. Of course there is no ultimate authority to enforce that this happens, Bitcoin is an entirely voluntary system. A contentious or disputed soft fork can be merged into a Bitcoin implementation at any time but doing this is opening the door to the schism, disruption and waste of developer hours that we saw in 2017. Personally I think we’ll see an attempt to activate a contentious soft fork at some point in the long term future (Murphy’s Law) but any attempt to do so should be strongly discouraged. It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem. Longer term I have confidence in Bitcoin’s ability to survive whatever happens but allocating significant community resources to resist an unnecessary contentious soft fork (or even regular contentious soft forks) is not an optimal use of those resources. Soft fork activation Miner signaling is a tool for signaling readiness. It is not voting for the soft fork or expressing support for the soft fork. There should not be any attempt to facilitate miner signaling until there is sufficient community consensus (the mining community is a subset of the community) on the soft fork. Merging activation parameters or encouraging miner signaling before it is clear there is community consensus on the entirety of the soft fork is putting the c
[bitcoin-dev] Wednesday’s second BIP process meeting
Wednesday’s second BIP process meeting was announced previously here [0]. A conversation log of the meeting is available here [1]. A summary of the first BIP process meeting is here [2]. The following is a summary of what was discussed. 1) The limits or possible downsides of pursuing maximal decentralization. Understandably there is a desire for greater decentralization as a central repo introduces bottlenecks and the need for maintainers or editors in the case of BIPs (prayank). However, zero filters creates a Ethereum style bewildering number of BIPs of varying quality that all need to be stored and maintained. The option of being able to store a BIP in any repo doesn’t appear to offer material upside (michaelfolkson). It still needs to get a BIP number from the BIP editors and if the alternative repo is deleted or the BIP champion becomes unresponsive there is the problem of changing the location of where the BIP is stored. It is much easier to monitor a single repo rather than an infinite number of repos that contain BIPs. 2) Past motivations for introducing alternative parallel processes to the BIPs (e.g. BOLTs, SLIPs). Anyone is free to set up a repo, add documentation to that repo or even set up a parallel process to the BIPs. However, if as a community we’d like to prevent unnecessary splintering it is good to understand why certain documents that should be BIPed aren’t being BIPed. Obviously not every document needs or should be BIPed. There are many docs that aren’t BIPs that are hugely valuable. One historical concern that was raised (ChristopherA) was regarding why BIP 48 didn’t happen and whether it was because it was coming from the wallet community and not a Bitcoin Core proposal. luke-jr said after the meeting that from recollection the reason it didn’t happen was merely that it was never written [3]. It was also discussed afterwards whether there was/is a rationale for Lightning BOLTs not being BIPs and whether they should be BIPs in future. 3) Kalle Alm’s proposal for BIP extensions [4] was discussed. Participants seemed to be in favor of the proposal though further clarity on when they would and wouldn’t be used was requested. A BIP extension for the bech32m update (BIP 350) to bech32 (BIP 173) seems like it would have been a good use case though further discussion is probably needed on whether they should be used for soft fork activation parameters. It was suggested that using dates and/or short extension names would be superior to extension numbers as numbers suggest an ordering (ChristopherA). The extension 2 may also be perceived as somehow replacing extension 1. Thanks to the participants of both BIP process meetings. Further discussion is welcome on the #bitcoin-dev Libera IRC channel and hopefully we will see progress in the coming weeks and months on a proposed BIP 3 [5] update. [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019412.html [1]: https://gist.github.com/michaelfolkson/84000ee3fe45c034ac12a7a54ff5fcdd [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019469.html [3]: https://github.com/bitcoin/bips/pull/253 [4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019457.html [5]: https://github.com/bitcoin/bips/pull/1015 -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Reminder: Second BIP process meeting tomorrow at 23:00 UTC
As announced here [0] there is a second BIP process meeting tomorrow (Wednesday September 29th 23:00 UTC). For Asia Pacific this is the morning of September 30th. It will be held on the #bitcoin-dev Libera IRC channel. A summary from the first meeting is here [1]. [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019412.html [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019469.html Thanks Michael Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Tuesday's BIP process meeting
Tuesday's BIP process meeting was announced previously here [0]. A conversation log of the meeting is available here [1]. It looks promising at this stage that we'll eventually have a bundle of changes to warrant a new proposed BIP (BIP 3) to replace the current BIP process that is described in BIP 2 [2]. Obviously there was only a very small group of attendees at this week's IRC meeting and so there should (and will) be ample time for the community (and this list) to review whatever changes are proposed before they are considered for merging into the BIPs repository and before they take effect. The following proposed changes were discussed: 1) An end to the 3 year rejection rule. In BIP 2 a BIP enters the "Rejected" state after 3 years if no progress had been made. The BIP champion then needs to address public criticism of the BIP to be able to leave the "Rejected" state. It is proposed instead that after 3 years the BIP would enter an "Inactive" state that only requires activity from the BIP champion to leave the "Inactive" state. 2) Currently BIP champions need to ACK pull requests with basic spelling/grammar changes before they can be merged. This is time consuming not only for the BIP editors who have to chase the BIP champions but it can be irritating for the BIP champions too especially if they champion multiple BIPs. It is proposed that BIP editors instead can use their judgment to merge in changes that don't impact the meaning of the BIP cc'ing the BIP champions and with reversions possible if the BIP champion is unhappy with the change. A single pull request making changes across multiple BIPs (e.g. spelling corrections) will not be considered for merging however. 3) BIP comments were introduced so that subject matter experts and informed critics of a proposal could make it clear to BIP readers and implementers of possible defects with the proposal. However, they have been rarely used and the few comments submitted on BIPs seem to have been widely ignored. Instead it is proposed that link(s) to bitcoin-dev mailing list post(s) with criticism or outlines of defects can be included within a BIP by the BIP editors such that the interested reader can easily be directed to the source of that information. 4) BIP champion(s) of soft fork BIPs containing consensus changes could theoretically include an activation method and parameters in their BIP unilaterally without consulting the broader community. (To be clear this is not necessarily what happened with Taproot activation parameters but there was confusion and disagreement about the role of BIPs and BIP editors in the perceived "finalization" of activation parameters.) This needs further discussion but proposed changes include sharpening the wording around activation parameters to make it clear that any parameters included are merely those recommended by the BIP champion(s) and don't necessarily have community consensus. Alternative proposals would be to not include activation methods or parameters within the BIP at all or to give BIP editors latitude to highlight concerns in a bitcoin-dev mailing list post and then include a link to that post within the BIP. For details of other changes discussed in the meeting please see the conversation log [1]. Kalle Alm has also sent an email [3] on BIP extensions to this list. The next meeting is on Wednesday September 29th (23:00 UTC) on the Libera IRC channel #bitcoin-dev. [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019412.html [1]: https://gist.github.com/michaelfolkson/f2870851bb812b4ac86006ea54ca78a2 [2]: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki [3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019457.html Michael Folkson Email: michaelfolk...@protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC
>> I can only speak for myself here but I am not particularly concerned about >> this perception of authority. > This perception affects Bitcoin. Personally I would rather have an optimal process that provides clarity and helps us build better software than be sensitive to inaccurate perceptions that hinder that ultimate goal. > Bitcoin Core is an implementation (used by most of the nodes right now). BIPs > are proposals for Bitcoin. Indeed, thanks for pointing this out. I take it as a given that everyone knows this but yeah when making such a comparison it is good to make this clear. > Using same organization on GitHub and such comparisons can be misleading for > many. I think there's an argument that BIPs could be under a different GitHub organization but it would be pretty low on my list or priorities. There is a clear divide between the group of Core maintainers and the group of BIP editors and in the absence of a reason to change that I would rather maintain the status quo. > I don't think we need ACKs/NACKs in BIPs repository and I feel weird to be a > part of discussions, ACKing this pull request: > https://github.com/bitcoin/bips/pull/1104. With BIP champions having more latitude in getting their BIP PR merged than they would for example getting their Core PR merged I agree ACK/NACKs on BIP PRs are less relevant. However, I still think some BIP champions would like to have their changes reviewed especially by subject matter experts. And if there are strong disagreements over the changes made an alternative BIP is always an option. I don't see the harm in having discussion with reviewers on BIP PRs and reviewers registering an ACK/NACK as long as we are all clear on what the BIP process is. > Not sure any Bitcoin project needs a pull request merged in this repository > to implement a proposal. I agree it is optional for some/many Bitcoin projects whether they are BIPed or not. Would you be comfortable with a soft fork/consensus code change going into Bitcoin Core without a BIP? I personally wouldn't. We should probably leave it at that to ensure we are not spamming the email list but hope to see you at the meeting later :) On Tue, Sep 14, 2021 at 3:50 PM Prayank wrote: > > > A mailing list post is static and a BIP will go normally go through > > multiple edits and revisions so you do need to take advantage of the Git > > version control system. It gets quite unwieldy to attempt to do that via a > > mailing list with every minor suggested edit getting sent to all > > subscribers. > > Mailing list post will have the link to BIP documentation. Post itself > doesn't need to be updated but same link can be used to share updated > information. Example: > https://gist.github.com/prayank23/95b4804777fefd015d7cc4f847675d7f (Image can > be changed in gist when required or add new information) > > Mailing list post will help in reading discussions related to proposal. > > >Also allowing the entire global population > (billions of people) to be able to create a directory doesn't sound > like a good idea to me :) > > There is nothing to allow/disallow. That's the whole point. People are free > to save links and organize things which can be called a BIP directory. > > > I can only speak for myself here but I am not particularly concerned about > > this perception of authority. > > This perception affects Bitcoin. > > > In the same way as there are limits on the ability of Core maintainers to > > unilaterally merge in contentious code changes there are similar limits on > > the ability of BIP editors. Ultimately anyone merging a PR has to consider > > process/consensus and concerns can (and have been in the past) be raised on > > this mailing list or elsewhere. > > Bitcoin Core is an implementation (used by most of the nodes right now). BIPs > are proposals for Bitcoin. Using same organization on GitHub and such > comparisons can be misleading for many. I don't think we need ACKs/NACKs in > BIPs repository and I feel weird to be a part of discussions, ACKing this > pull request: https://github.com/bitcoin/bips/pull/1104. Not sure any Bitcoin > project needs a pull request merged in this repository to implement a > proposal. > > > I'm not sure where you are suggesting a bot should be. > > A bot similar to DrahtBot in Bitcoin Core repository. > > Few other developers had suggested similar thing earlier: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018868.html > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018869.html > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018871.html > > -- > Prayank > > A3B1 E430 2298 178F > > > > Sep 14, 2021, 19:37 by michaelfolk...@gmail.com: > > Hey Prayank > > Thanks for the suggestions. > > bitcoin-dev mailing list link can be considered a BIP and saved in a BIP > directory. Anyone can creat
Re: [bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC
Hey Prayank Thanks for the suggestions. > bitcoin-dev mailing list link can be considered a BIP and saved in a BIP > directory. Anyone can create such directories. So BIP is nothing but a > proposal shared on bitcoin-dev mailing list. A mailing list post is static and a BIP will go normally go through multiple edits and revisions so you do need to take advantage of the Git version control system. It gets quite unwieldy to attempt to do that via a mailing list with every minor suggested edit getting sent to all subscribers. Also allowing the entire global population (billions of people) to be able to create a directory doesn't sound like a good idea to me :) > This will avoid the 'bitcoin/bips' repository being considered as some BIP > authority that approves BIPs and proposals can improve Bitcoin without using > the repository. Repository will only be helpful in documenting BIP correctly. I can only speak for myself here but I am not particularly concerned about this perception of authority. We need a central repo that we can all refer to (rather than BIPs being distributed across a large number of repos) and that central repo needs to managed and maintained by somebody (in this case the two BIP editors Kalle and Luke). In the same way as there are limits on the ability of Core maintainers to unilaterally merge in contentious code changes there are similar limits on the ability of BIP editors. Ultimately anyone merging a PR has to consider process/consensus and concerns can (and have been in the past) be raised on this mailing list or elsewhere. > 2. Bot in `bitcoin/bips` repository that notifies about pull requests based > on different things. This will help maintainer(s) and contributors. I'm not sure where you are suggesting a bot should be. On IRC? There is a BIP merges bot on Mastodon[0] that I'm aware of and obviously you can subscribe to GitHub repo notification emails. > 3. BIP Gallery: I tried sharing things in a different way so that newbies can > understand importance of BIPs in Bitcoin and relate to it: > https://prayank23.github.io/BIPsGallery/ however couldn't complete it with > all the BIPs because not many people considered it helpful. There were few > suggestions to improve it by adding some text for each BIP and better image > gallery. Maybe someone else can create a better project. This looks cool. I think we can definitely do better in encouraging more people to engage with the BIP process especially as the ideas start flowing in post Taproot activation brainstorming what should be in the "next soft fork" (trademark!). Some of the BIPs (e.g. the Taproot BIPs 340-342) are quite technically dense so someone on IRC suggested making greater use of informational BIPs to supplement the standard BIPs for new implementers or even casual readers. [0] https://x0f.org/@bipmerges On Tue, Sep 14, 2021 at 1:17 PM Prayank wrote: > > Hi Michael, > > Thanks for sharing the details about the meeting. > > Wishlist has some interesting points. I would like to suggest few things: > > 1.BIP process: > > A. Plan and document a proposal > > B. Open PR in https://github.com/bitcoin/bips and edit everything properly > > C. BIP is assigned a number and merged > > D. Share the proposal on bitcoin dev mailing list > > bitcoin-dev mailing list link can be considered a BIP and saved in a BIP > directory. Anyone can create such directories. So BIP is nothing but a > proposal shared on bitcoin-dev mailing list. > > Who implements the BIP? When is it implemented? How is it implemented? > Opinions on proposal etc. will be different for each BIP. This will avoid the > 'bitcoin/bips' repository being considered as some BIP authority that > approves BIPs and proposals can improve Bitcoin without using the repository. > Repository will only be helpful in documenting BIP correctly. > > 2. Bot in `bitcoin/bips` repository that notifies about pull requests based > on different things. This will help maintainer(s) and contributors. > > 3. BIP Gallery: I tried sharing things in a different way so that newbies can > understand importance of BIPs in Bitcoin and relate to it: > https://prayank23.github.io/BIPsGallery/ however couldn't complete it with > all the BIPs because not many people considered it helpful. There were few > suggestions to improve it by adding some text for each BIP and better image > gallery. Maybe someone else can create a better project. > > > -- > Prayank > > A3B1 E430 2298 178F -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
> Can you explain the motivation for this? From where I sit, as far as I know, > I should basically be > a prime example of the target market for public > signet - someone developing bitcoin applications > with regular requirements > to test those applications with other developers without > jumping through hoops to configure software the same across the globe and set > up miners. > With blocks > being slow and irregular, I’m basically not benefited at all by > signet and will > stick with testnet3/mainnet testing, which both suck. On testnet3 you can realistically go days without blocks being found (and conversely thousands of blocks can be found in a day), the block discovery time variance is huge. Of course this is probabilistically possible on mainnet too but the probability of this happening is close to zero. Here[0] is an example of 16,000 blocks being found in a day on testnet3. On signet block discovery time variance mirrors mainnet. On mainnet you are risking Bitcoin with actual monetary value. If you don't mind doing this then you don't need testnet3, signet or anything else. In addition proposed soft forks may be activated on signet (and could also be on testnet3) well before they are considered for activation on mainnet for testing and experimentation purposes. [0] https://web.archive.org/web/20160910173004/https://blog.blocktrail.com/2015/04/in-the-darkest-depths-of-testnet3-16k-blocks-were-found-in-1-day/ -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
> Huh? Why would the goal be to match mainnet? The goal, as I understand it, is > to allow software to use SigNet without modification *to make testing simpler* - keep the header format the same to let SPV clients function without (significant) modification, etc. The point of the whole thing is to make testing as easy as possible, why would we do otherwise. I guess Kalle (and AJ) can answer this question better than me but my understanding is that the motivation for Signet was that testnet deviated erratically from mainnet behavior (e.g. long delays before any blocks were mined followed by a multitude of blocks mined in a short period of time) which meant it wasn't conducive to normal testing of applications. Why would you want a mainnet like chain? To check if your application works on a mainnet like chain without risking any actual value before moving to mainnet. The same purpose as testnet but more reliably resembling mainnet behavior. You are well within your rights to demand more than that but my preference would be to push some of those demands to custom signets rather than the default Signet. Testing out proposed soft forks in advance of them being considered for activation would already be introducing a dimension of complexity that is going to be hard to manage [0]. I'm generally of the view that if you are going to introduce a complexity dimension, keep the other dimensions as vanilla as possible. Otherwise you are battling complexity in multiple different dimensions and it becomes hard or impossible to maintain it and meet your initial objectives. But if this feature of extremely regular re-orgs is an in demand feature for testers I think the question then becomes what the default be (I would suggest re-orgs every 8 hours rather than no re-orgs at all) and then the alternative which you can switch to, re-orgs every block or every 6 blocks or whatever. > I believe my suggestion was not correctly understood. I'm not suggesting > *users* sign blocks or otherwise do anything manually here, only that the existing block producers each generate a new key, and we then only sign reorgs with *those* keys. Users will be able to set a flag to indicate "I want to accept sigs from either sets of keys, and see reorgs" or "I only want sigs from the non-reorg keys, and will consider the reorg keys-signed blocks invalid" Ah I did misunderstand, yes this makes more sense. Thanks for the correction. [0] https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-signet-with-multiple-proposed-soft-forks-whilst-maintaining On Fri, Sep 10, 2021 at 7:24 PM Matt Corallo wrote: > > > > On 9/10/21 06:05, Michael Folkson wrote: > >> I see zero reason whatsoever to not simply reorg ~every block, or as often > >> as is practical. If users opt in to wanting to test with reorgs, they > >> should be able to test with reorgs, not wait a day to test with reorgs. > > > > One of the goals of the default Signet was to make the default Signet > > resemble mainnet as much as possible. (You can do whatever you want on > > a custom signet you set up yourself including manufacturing a re-org > > every block if you wish.) Hence I'm a bit wary of making the behavior > > on the default Signet deviate significantly from what you might > > experience on mainnet. Given re-orgs don't occur that often on mainnet > > I can see the argument for making them more regular (every 8 hours > > seems reasonable to me) on the default Signet but every block seems > > excessive. It makes the default Signet into an environment for purely > > testing whether your application can withstand various flavors of edge > > case re-orgs. You may want to test whether your application can > > withstand normal mainnet behavior (no re-orgs for long periods of > > time) first before you concern yourself with re-orgs. > > Huh? Why would the goal be to match mainnet? The goal, as I understand it, is > to allow software to > use SigNet without modification *to make testing simpler* - keep the header > format the same to let > SPV clients function without (significant) modification, etc. The point of > the whole thing is to > make testing as easy as possible, why would we do otherwise. > > Further, because one goal here is to enable clients to opt in or out of the > reorg chain at will > (presumably by just changing one config flag in bitcoin.conf), why would we > worry about making it > "similar to mainnet". If users want an experience "similar to mainnet", they > can simply turn off > reorgs and they'll see a consistent chain moving forward which never reorgs, > similar to the > practical experience of mainnet. > > Once you've opted into reorgs, you almost certainly are looking to *test* > reorgs - you just > restarted Bitcoin Core with the reorg flag set, waiting around for a reorg > after doing that seems > like the experience of testnet3 today, and the whole reason why we wanted > signet to begin with - > things happen sporadically and in
Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
> I see zero reason whatsoever to not simply reorg ~every block, or as often as > is practical. If users opt in to wanting to test with reorgs, they should be > able to test with reorgs, not wait a day to test with reorgs. One of the goals of the default Signet was to make the default Signet resemble mainnet as much as possible. (You can do whatever you want on a custom signet you set up yourself including manufacturing a re-org every block if you wish.) Hence I'm a bit wary of making the behavior on the default Signet deviate significantly from what you might experience on mainnet. Given re-orgs don't occur that often on mainnet I can see the argument for making them more regular (every 8 hours seems reasonable to me) on the default Signet but every block seems excessive. It makes the default Signet into an environment for purely testing whether your application can withstand various flavors of edge case re-orgs. You may want to test whether your application can withstand normal mainnet behavior (no re-orgs for long periods of time) first before you concern yourself with re-orgs. > Why bother with a version bit? This seems substantially more complicated than > the original proposal that surfaced many times before signet launched to just > have a different reorg signing key. Thus, users who wish to follow reorgs can > use a 1-of-2 (or higher multisig) and users who wish to not follow reorgs > would use a 1-of-1 (or higher multisig), simply marking the reorg blocks as > invalid without touching any header bits that non-full clients will ever see. If I understand this correctly this is introducing a need for users to sign blocks when currently with the default Signet the user does not need to concern themselves with signing blocks. That is entirely left to the network block signers of the default Signet (who were AJ and Kalle last time I checked). Again I don't think this additional complexity is needed on the default Signet when you can set up your own custom Signet if you want to test edge case scenarios that deviate significantly from what you are likely to experience on mainnet. A flag set via a configuration argument (the AJ, 0xB10C proposal) with no-reorgs (or 8 hour re-orgs) as the default seems to me like it would introduce no additional complexity to the casual (or alpha stage) tester experience though of course it introduces implementation complexity. To move the default Signet in the direction of resembling mainnet even closer would be to randomly generate batches of transactions to fill up blocks and create a fee market. It would be great to be able to test features like RBF and Lightning unhappy paths (justice transactions, perhaps even pinning attacks etc) on the default Signet in future. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC
With a new BIP editor (Kalle Alm) in place and Taproot activation locked in it is probably/possibly as good time as any to revisit the BIP process and see if we can bolster it, improve it or at least inform why certain things operate the way they do. Hence two IRC meetings are being organized, one on Tuesday September 14th (23:00 UTC) and one on Wednesday September 29th (23:00 UTC), both on the Libera IRC channel #bitcoin-dev. Possible discussion topics range from the relatively mundane (should BIP champions need to ACK basic spelling change PRs) to the possibly contentious (what role if any do the BIPs have in informing the community of soft fork activation parameters). At the very least it would be good to address some common misunderstandings and subtleties of the BIP process that many (including myself) are lacking context on. So if you are interested in the BIP process or certainly if you have experienced frustrations with the BIP process in the past as a BIP champion or BIP contributor please attend and we’ll see what progress we can make. There is a BIP process wishlist that some have already contributed ideas too: https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist And of course BIP 2 outlines the current BIP process: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki This is being organized in the spirit of seeking to improve a process and a resource that we as a community all rely on so please engage in the spirit that is intended. I will keep the mailing list informed of anything that comes out of the meetings and the #bitcoin-dev channel is open for discussion outside of the meetings. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Is there a tool like Ethereum EVM at present for Bitcoin script?
The "No Taproot" section of the Sapio docs need updating :) What are your plans to take advantage of Taproot with Sapio? It would have been interesting to see what a Taproot emulator would have looked like, although no need for it now. It seems to me Taproot would have been harder to emulate than CTV though I could be wrong. https://learn.sapio-lang.org/ch05-02-taproot.html Also there have been a number of people asking questions about Sapio and CTV on the Libera equivalents of Freenode channels #sapio and ##ctv-bip-review over the past months. Do you plan to join and claim those channels? Date: Thu, 26 Aug 2021 03:26:23 -0700 From: Jeremy To: Andrew Poelstra , Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Is there a tool like Ethereum EVM at present for Bitcoin script? Message-ID: Content-Type: text/plain; charset="utf-8" This has actually never been true (Sapio assumes extensions). If the extensions are not present, you can stub them out with a signing federation instead, configurable as flags, and you can also write many contracts that do not use the ctv based components at all. The protocol for emulation is a bit clever (if I do say so myself) since it ensures that contract compilation is completely offline and the oracles are completely stateless. Relevant links: https://learn.sapio-lang.org/ch05-01-ctv-emulator.html https://learn.sapio-lang.org/ch03-02-finish.html Cheers, Jeremy -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Online discussion on Taproot roll out - Tuesday July 20th 17:15 UTC
Please find below the video and transcript from the online discussion on Taproot roll out that was held on July 20th. Video: https://www.youtube.com/watch?v=GAkLuZNsZzw Transcript: https://btctranscripts.com/london-bitcoin-devs/2021-07-20-socratic-seminar-taproot-rollout/ Reading list: https://gist.github.com/michaelfolkson/0803271754f851530fe8242087859254 On Sat, Jul 17, 2021 at 2:16 PM Michael Folkson wrote: > > Hi > > There is an online Zoom call (also livestreamed on YouTube) on Tuesday > July 20th at 17:15 UTC discussing Taproot roll out post activation in > November. It will be focused at developers and so discussion will be > technical but all are welcome to attend/watch. > > Murch has this wiki page monitoring planned ecosystem support of P2TR > addresses and it would be great to hear from projects and businesses > that have Taproot support on their medium/long term development > roadmap or are considering it: > https://en.bitcoin.it/wiki/Bech32_adoption > > Meetup link (Zoom link will be announced here): > https://www.meetup.com/BitDevsLDN/events/279041693/ > > Draft pre-reading link (will be finalized before Tuesday): > https://gist.github.com/michaelfolkson/0803271754f851530fe8242087859254 > > Thanks > Michael > > -- > Michael Folkson > Email: michaelfolk...@gmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Last week's second IRC workshop on L2 onchain support and wrap up
There was some additional discussion on L2 onchain support at the
recent online Sydney Socratic Seminar. It wasn't recorded but a
transcript is below.
Transcript:
https://btctranscripts.com/sydney-bitcoin-meetup/2021-07-06-socratic-seminar/
The discussion focused partly on the rules [1] of BIP 125 RBF and the
rationale for these rules (which isn't clear from the BIP). Proposed
ideas such as SIGHASH_IOMAP, fee sponsorship and transaction mutation
were also discussed that weren't covered during the IRC workshops.
[1]
https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implementation-details
On Tue, Jun 29, 2021 at 10:44 AM Michael Folkson
wrote:
>
> A summary of the first workshop is here:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019079.html
>
> The focus for this second workshop was fee bumping and package relay.
> For more details on package relay see:
> https://github.com/ariard/L2-zoology/blob/master/workshops/package-relay-and-friends.md
>
> The conversation log for the second workshop is here:
> https://gist.github.com/ariard/32b51ecceccc5c6f647bae86d083c442
>
> Package relay background
>
> Package relay is potentially useful for L2 protocols to address the
> inherent unpredictability of future fees. CPFP (child-pays-for-parent)
> seeks to ensure say a justice transaction, in Lightning’s case, with a
> lower fee, gets confirmed in a more timely manner because miners are
> incentivized to include the child transaction in a block. To do so
> they must include the parent transaction in that block or a preceding
> block. By “packaging” the parent and the child the initiator of the
> transaction(s) can ensure the miner’s mempool doesn’t initially reject
> the parent transaction for having a too low fee.
>
> There has been prior work done in previous years on package relay,
> mainly by Suhas Daftuar.
>
> Draft BIP: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
>
> Package relay design questions:
> https://github.com/bitcoin/bitcoin/issues/14895
>
> Recently Gloria Zhao has been advancing package relay in Bitcoin Core:
> https://gist.github.com/glozow/7064717e727a3eb27fad4f8504513add
>
> Package relay implementation
>
> Attendees seemed in agreement that enabling 2 transaction packages
> would be sufficient (at least for now) for Lightning and DLCs. A L2
> protocol should always be able to design a two step process where the
> first transaction has an effective zero fee rate and the second
> transaction sets the fee. Restricting the size of the package to 2 may
> have the cost of slightly longer confirmation times and/or slightly
> higher fees (t-bast) but it compares well to the increased
> implementation complexity of larger package sizes. Two generation:
> multi parent, single child shouldn’t introduce material implementation
> complexity over two generation: single parent, single child (glozow).
>
> Package RBF (replace-by-fee) is possible where there are two competing
> packages with competing Lightning commitment transactions in them and
> the second package is given a higher fee to attempt to get it
> confirmed before the first package. However, supporting RBF within a
> package (ie replacing a transaction in a package with a higher fee
> transaction) increases implementation complexity and makes it harder
> to reason about (glozow).
>
> rgrant raised the possibility of using two packages {A,B} and {B,C} if
> three transaction packages e.g. {A,B,C} weren’t supported but it was
> suggested it is perhaps better to just broadcast a high fee CPFP
> transaction for the {A,B} package rather than creating two packages.
> If the first package has been evicted from the mempool the {B,C}
> package wouldn’t propagate because it would be an orphan package
> (t-bast).
>
> glozow suggested that only hints (wtxids of transactions you think
> should be package validated) could be communicated rather than
> relaying the transaction themselves but there were concerns from
> others on whether these hints would successfully propagate across the
> network. Instead fee rate hints could be sent to inform a peer’s
> decision on whether it makes sense to fetch the rest of the package
> (t-bast).
>
> darosior suggested the idea of a package based CBlockPolicyEstimator
> in Bitcoin Core if CPFP is going to be increasingly used on the
> network.
>
> Witness replacement and Taproot
>
> Tapscripts can be unlimited in size so with current Taproot rules you
> could in theory go from a 100,000 vbyte witness to an empty witness.
> L2 protocols may have a UTXO shared by two parties where Alice’s
> witness for her branch is say 1,000 vbytes and Bob’s witness is only
> say 250 vbytes. Replacing Alice’s larger witness with Bob’s smaller
> witness could reduce transaction fees. For Lightning the best case is
> a Taproot key path spend (16 vbyte witness) and the worst case is
> going to be a 150 vbyte witness. Miniscript can tell you your worst
> case transaction size and this
[bitcoin-dev] Online discussion on Taproot roll out - Tuesday July 20th 17:15 UTC
Hi There is an online Zoom call (also livestreamed on YouTube) on Tuesday July 20th at 17:15 UTC discussing Taproot roll out post activation in November. It will be focused at developers and so discussion will be technical but all are welcome to attend/watch. Murch has this wiki page monitoring planned ecosystem support of P2TR addresses and it would be great to hear from projects and businesses that have Taproot support on their medium/long term development roadmap or are considering it: https://en.bitcoin.it/wiki/Bech32_adoption Meetup link (Zoom link will be announced here): https://www.meetup.com/BitDevsLDN/events/279041693/ Draft pre-reading link (will be finalized before Tuesday): https://gist.github.com/michaelfolkson/0803271754f851530fe8242087859254 Thanks Michael -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Last week's second IRC workshop on L2 onchain support and wrap up
A summary of the first workshop is here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019079.html
The focus for this second workshop was fee bumping and package relay.
For more details on package relay see:
https://github.com/ariard/L2-zoology/blob/master/workshops/package-relay-and-friends.md
The conversation log for the second workshop is here:
https://gist.github.com/ariard/32b51ecceccc5c6f647bae86d083c442
Package relay background
Package relay is potentially useful for L2 protocols to address the
inherent unpredictability of future fees. CPFP (child-pays-for-parent)
seeks to ensure say a justice transaction, in Lightning’s case, with a
lower fee, gets confirmed in a more timely manner because miners are
incentivized to include the child transaction in a block. To do so
they must include the parent transaction in that block or a preceding
block. By “packaging” the parent and the child the initiator of the
transaction(s) can ensure the miner’s mempool doesn’t initially reject
the parent transaction for having a too low fee.
There has been prior work done in previous years on package relay,
mainly by Suhas Daftuar.
Draft BIP: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
Package relay design questions: https://github.com/bitcoin/bitcoin/issues/14895
Recently Gloria Zhao has been advancing package relay in Bitcoin Core:
https://gist.github.com/glozow/7064717e727a3eb27fad4f8504513add
Package relay implementation
Attendees seemed in agreement that enabling 2 transaction packages
would be sufficient (at least for now) for Lightning and DLCs. A L2
protocol should always be able to design a two step process where the
first transaction has an effective zero fee rate and the second
transaction sets the fee. Restricting the size of the package to 2 may
have the cost of slightly longer confirmation times and/or slightly
higher fees (t-bast) but it compares well to the increased
implementation complexity of larger package sizes. Two generation:
multi parent, single child shouldn’t introduce material implementation
complexity over two generation: single parent, single child (glozow).
Package RBF (replace-by-fee) is possible where there are two competing
packages with competing Lightning commitment transactions in them and
the second package is given a higher fee to attempt to get it
confirmed before the first package. However, supporting RBF within a
package (ie replacing a transaction in a package with a higher fee
transaction) increases implementation complexity and makes it harder
to reason about (glozow).
rgrant raised the possibility of using two packages {A,B} and {B,C} if
three transaction packages e.g. {A,B,C} weren’t supported but it was
suggested it is perhaps better to just broadcast a high fee CPFP
transaction for the {A,B} package rather than creating two packages.
If the first package has been evicted from the mempool the {B,C}
package wouldn’t propagate because it would be an orphan package
(t-bast).
glozow suggested that only hints (wtxids of transactions you think
should be package validated) could be communicated rather than
relaying the transaction themselves but there were concerns from
others on whether these hints would successfully propagate across the
network. Instead fee rate hints could be sent to inform a peer’s
decision on whether it makes sense to fetch the rest of the package
(t-bast).
darosior suggested the idea of a package based CBlockPolicyEstimator
in Bitcoin Core if CPFP is going to be increasingly used on the
network.
Witness replacement and Taproot
Tapscripts can be unlimited in size so with current Taproot rules you
could in theory go from a 100,000 vbyte witness to an empty witness.
L2 protocols may have a UTXO shared by two parties where Alice’s
witness for her branch is say 1,000 vbytes and Bob’s witness is only
say 250 vbytes. Replacing Alice’s larger witness with Bob’s smaller
witness could reduce transaction fees. For Lightning the best case is
a Taproot key path spend (16 vbyte witness) and the worst case is
going to be a 150 vbyte witness. Miniscript can tell you your worst
case transaction size and this can be used to assess the transaction
pinning risk of a bloated witness (all harding).
A future soft fork could give meaning to the annex in Taproot
(darosior) which could be used for inflating the fee rate of a
witness. Then you could have a same-txid-different-wtxid coming after
with a lower fee rate but higher vbytes size to override package
limits (ariard). But fee rate is purely a policy concept and the annex
operates at the consensus level. In addition the annex can only
increase the weight of a transaction, it cannot decrease it (harding).
Wrap up and initial goals
With regards to the goals of the workshops that were initially
announced here:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/003002.html
1) 2 transactions packages sounds enough to support currently deployed
L2 protocols
Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support
Sure, feel free to continue on this thread for discussion of fee sensitive timelocks. I'll start a new thread for a summary of today's second workshop. On Tue, Jun 22, 2021 at 7:26 PM Billy Tetrud wrote: > > > where is the current network fee rate obtained from and how is it fed into > > the script? > > It could be obtained as something like the median transaction fee rate over a > window of X blocks. Its something any full node could easily keep track of. > And as long as hour-level or day-level granularity is acceptable, I wouldn't > think there'd be any need to incorporate mempool information (if that were > even possible without introducing new attack vectors). Let me know if this > isn't an appropriate thread to discuss this in. > > On Tue, Jun 22, 2021 at 11:21 AM Michael Folkson > wrote: >> >> Hey Billy >> >> No, fee sensitive timelocks weren't discussed at any length in the >> workshop. The workshops are obviously time limited but if they spur >> future discussion and drafted proposals (whether they need soft forks >> or not) outside of the workshops that would be great. This idea was >> raised in the meeting by Ruben Somsen so maybe Ruben has given them >> some thought. Making timelocks conditional on the current fee rate >> seems challenging to me (where is the current network fee rate >> obtained from and how is it fed into the script?) but I haven't >> sketched out exactly how they would work. >> >> A reminder that the second workshop (on package relay and fee bumping) >> starts at 19:00 UTC today (30 minutes after I've sent this, there may >> be a delay before it is published to the mailing list). >> >> Thanks >> Michael >> >> On Tue, Jun 22, 2021 at 7:02 PM Billy Tetrud wrote: >> > >> > Thanks for the Summary Michael! >> > >> > It seems like fee-sensitive timelocks weren't discussed too much in the >> > workshop, unless I'm missing something. I also don't see any downside to >> > it discussed (other than that it needs a soft-fork). It seems like that >> > would be a great way to substantially increase the resilience of the LN to >> > temporary periods of fee congestion, even potentially long-running periods >> > that last weeks. It might even help in non-temporary fee market increases >> > by giving participants extra time to use some fee-bumping technique to >> > close or restructure their channels to compensate for the elevated fee >> > market. >> > >> > On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev >> > wrote: >> >> >> >> The workshop was previously announced by ariard on the bitcoin-dev >> >> mailing list here: >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841.html >> >> >> >> A reminder was posted to the bitcoin-dev mailing list here: >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.html >> >> >> >> The conversation log for the workshop is here: >> >> https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4 >> >> >> >> I’ll summarize what was discussed during the meeting but please refer >> >> to the L2 zoology repo ariard has set up for background context and >> >> additional notes: https://github.com/ariard/L2-zoology >> >> >> >> General considerations >> >> >> >> I think it is worth first reiterating the obvious that there will >> >> never be perfect security guarantees on network transaction fee rates >> >> or transaction relay. Network fee rates can in theory go up to >> >> anything (upper limit of infinity) and will always to some degree be >> >> inherently unpredictable. In addition transaction acceptance can never >> >> be guaranteed even if you attempt a direct connection to a miner. At >> >> the same time L2 protocols (e.g. Lightning and DLCs) elevate >> >> transaction propagation and inclusion in a time sensitive mined block >> >> to a security assumption from what used to just be a usability >> >> assumption (BlueMatt). Within those confines these workshops are >> >> attempting to strengthen that security assumption knowing that >> >> guaranteeing it is out of reach. >> >> >> >> There are considerations that blocked transaction propagation isn’t >> >> necessarily a problem for the victim if it is also blocked for the >> >&
Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support
Hey Billy No, fee sensitive timelocks weren't discussed at any length in the workshop. The workshops are obviously time limited but if they spur future discussion and drafted proposals (whether they need soft forks or not) outside of the workshops that would be great. This idea was raised in the meeting by Ruben Somsen so maybe Ruben has given them some thought. Making timelocks conditional on the current fee rate seems challenging to me (where is the current network fee rate obtained from and how is it fed into the script?) but I haven't sketched out exactly how they would work. A reminder that the second workshop (on package relay and fee bumping) starts at 19:00 UTC today (30 minutes after I've sent this, there may be a delay before it is published to the mailing list). Thanks Michael On Tue, Jun 22, 2021 at 7:02 PM Billy Tetrud wrote: > > Thanks for the Summary Michael! > > It seems like fee-sensitive timelocks weren't discussed too much in the > workshop, unless I'm missing something. I also don't see any downside to it > discussed (other than that it needs a soft-fork). It seems like that would be > a great way to substantially increase the resilience of the LN to temporary > periods of fee congestion, even potentially long-running periods that last > weeks. It might even help in non-temporary fee market increases by giving > participants extra time to use some fee-bumping technique to close or > restructure their channels to compensate for the elevated fee market. > > On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev > wrote: >> >> The workshop was previously announced by ariard on the bitcoin-dev >> mailing list here: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841.html >> >> A reminder was posted to the bitcoin-dev mailing list here: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.html >> >> The conversation log for the workshop is here: >> https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4 >> >> I’ll summarize what was discussed during the meeting but please refer >> to the L2 zoology repo ariard has set up for background context and >> additional notes: https://github.com/ariard/L2-zoology >> >> General considerations >> >> I think it is worth first reiterating the obvious that there will >> never be perfect security guarantees on network transaction fee rates >> or transaction relay. Network fee rates can in theory go up to >> anything (upper limit of infinity) and will always to some degree be >> inherently unpredictable. In addition transaction acceptance can never >> be guaranteed even if you attempt a direct connection to a miner. At >> the same time L2 protocols (e.g. Lightning and DLCs) elevate >> transaction propagation and inclusion in a time sensitive mined block >> to a security assumption from what used to just be a usability >> assumption (BlueMatt). Within those confines these workshops are >> attempting to strengthen that security assumption knowing that >> guaranteeing it is out of reach. >> >> There are considerations that blocked transaction propagation isn’t >> necessarily a problem for the victim if it is also blocked for the >> attacker. In addition some successful attacks present an opportunity >> for the victim to divert their funds to miner fees (e.g. scorched >> earth) ensuring the attacker doesn’t financially benefit from the >> attack (harding). Personally I would argue neither of these present >> much assurance to the victim. Out of conservatism one should assume >> that the attacker has greater resources than the victim (e.g. a direct >> line to a miner) and knowing a victim’s lost funds went to the miner >> instead of the attacker isn’t of much comfort to the victim (other >> than potentially presenting a disincentive for the attack in the first >> place). This is obviously further complicated if the miner is the >> attacker. In addition any incentive for miners to not mine >> transactions to wait for a potential pay-all-to-fee are troubling >> (t-bast). >> >> New(ish) ideas >> >> RubenSomsen brought up the idea of fee sensitive timelocks, they would >> need a soft fork. ariard briefly discussed the idea of a transaction >> relay overlay network. harding stated his opinion that we should be >> leaning more on miners’ profit incentive rather than attempting to >> normalize mempool policy (e.g. >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html). >> t-bast raised the prospect of mining pools exposing public APIs to >> push them transa
Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages
I don't want to divert from the topic of this thread ("Waiting
SIGHASH_ANYPREVOUT and Packing Packages"), we can set up a separate
thread if we want to discuss this further. But just a couple of
things.
> Browsing quickly through Greg's piece, a lot of the reasoning is based on
> FOSS experience from Linux/Juniper, which to the best of my knowledge are
> centralized software projects ?
That is Greg's point. If Linux doesn't look further than the current
version and the next version with a BDFL (Linus) a decentralized
project like Bitcoin Core is going to struggle even more with longer
term roadmaps.
I think it is important to discuss what order changes should be
attempted but I agree with David that putting specific future version
numbers on changes is speculative at best and misleading at worst. The
record of previous predictions of what will be included in particular
future versions is not strong :)
> What was making sense when you had like ~20 Bitcoin dev with 90% of the
> technical knowledge doesn't scale when you have multiple second-layers
> specifications
It is great that we have a larger set of contributors in the ecosystem
today than back in say pre 2017. But today that set of contributors is
spread widely across a number of different projects that didn't exist
pre 2017. Changes to Core are (generally) likely to be implemented and
reviewed by current Core contributors as Lightning implementation
developers (generally) seem to have their hands full with their own
implementations.
I think we can get the balance right by making progress on this
(important) discussion whilst also maintaining humility that we don't
know exact timelines and that getting things merged into Core relies
on a number of people who have varying levels of interest and
understanding of L2 protocols.
On Mon, Jun 21, 2021 at 9:13 AM Antoine Riard wrote:
>
> Hi Dave,
>
> > That might work for current LN-penalty, but I'm not sure it works for
> eltoo.
>
> Well, we have not settled yet on the eltoo design but if we take the later
> proposal in date [0], signing the update transaction with SIGHGASH_ANYPREVOUT
> lets you attach non-interactively a single-party controlled input at
> broadcast-time. Providing the input amount is high enough to bump the
> transaction feerate over network mempools, it should allow the tx to
> propagate across network mempools and that way solve the pre-signed feerate
> problem as defined in the post ?
>
> > If Bitcoin Core can rewrite the blind CPFP fee bump transaction
> > to refer to any prevout, that implies anyone else can do the same.
> > Miners who were aware of two or more states from an eltoo channel would
> > be incentivized to rewrite to the oldest state, giving them fee revenue
> > now and ensuring fee revenue in the future when a later state update is
> > broadcast.
>
> Yep, you can add a per-participant key to lockdown the transaction and avoid
> any in-flight malleability ? I think this is discussed in the "A Stroll
> through Fee-Bumping Techniques" thread.
>
> > If the attacker using pinning is able to reuse their attack at no cost,
> > they can re-pin the channel again and force the honest user to pay
> > another anyprevout bounty to miners.
>
> This is also true with package-relay where your counterparty, with a better
> knowledge of network mempools, can always re-broadcast a CPFP-bumped
> malicious package ? Under this assumption, I think you should always be ready
> to bump our honest package.
>
> Further, for the clarity of the discussion, can you point to which pinning
> scenario you're thinking of or if it's new under SIGHASH_ANYPREVOUT, describe
> it ?
>
> > Repeat this a bunch of times and the honest user has now spent more on fees
> > than their balance from the
> closed channel.
>
> And sadly, as this concern also exists in case of a miner-harvesting attack
> against LN nodes, a concern that Gleb and I expressed more than a year ago in
> a public post [1], a good L2 client should always upper bound its fee-bumping
> reserve. I've a short though-unclear note on this notion of fee-bumping upper
> to warn other L2 engineers in "On Mempool Funny Games against Multi-Party
> Funded Transactions"
>
> Please read so:
>
> "A L2 client, with only a view of its mempool at best, won't understand why
> the transaction doesn't confirm and if it's responsible for the
> fee-bumping, it might do multiple rounds of feerate increase through CPFP,
> in vain. As the fee-bumping algorithm is assumed to be known if the victim
> client is open source code, the attacker can predict when the fee-bumping
> logic reaches its upper bound."
>
> Though thanks for the recall! I should log dynamic-balances in RL's
> `ChannelMonitorUpdate` for our ongoing implementation of anchor, updating my
> TODO :p
>
> > Even if my analysis above is wrong, I would encourage you or Matt or
> someone to write up this anyprevout idea in more detail and distribute
> it before you promote i
[bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support
The workshop was previously announced by ariard on the bitcoin-dev mailing list here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841.html A reminder was posted to the bitcoin-dev mailing list here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.html The conversation log for the workshop is here: https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4 I’ll summarize what was discussed during the meeting but please refer to the L2 zoology repo ariard has set up for background context and additional notes: https://github.com/ariard/L2-zoology General considerations I think it is worth first reiterating the obvious that there will never be perfect security guarantees on network transaction fee rates or transaction relay. Network fee rates can in theory go up to anything (upper limit of infinity) and will always to some degree be inherently unpredictable. In addition transaction acceptance can never be guaranteed even if you attempt a direct connection to a miner. At the same time L2 protocols (e.g. Lightning and DLCs) elevate transaction propagation and inclusion in a time sensitive mined block to a security assumption from what used to just be a usability assumption (BlueMatt). Within those confines these workshops are attempting to strengthen that security assumption knowing that guaranteeing it is out of reach. There are considerations that blocked transaction propagation isn’t necessarily a problem for the victim if it is also blocked for the attacker. In addition some successful attacks present an opportunity for the victim to divert their funds to miner fees (e.g. scorched earth) ensuring the attacker doesn’t financially benefit from the attack (harding). Personally I would argue neither of these present much assurance to the victim. Out of conservatism one should assume that the attacker has greater resources than the victim (e.g. a direct line to a miner) and knowing a victim’s lost funds went to the miner instead of the attacker isn’t of much comfort to the victim (other than potentially presenting a disincentive for the attack in the first place). This is obviously further complicated if the miner is the attacker. In addition any incentive for miners to not mine transactions to wait for a potential pay-all-to-fee are troubling (t-bast). New(ish) ideas RubenSomsen brought up the idea of fee sensitive timelocks, they would need a soft fork. ariard briefly discussed the idea of a transaction relay overlay network. harding stated his opinion that we should be leaning more on miners’ profit incentive rather than attempting to normalize mempool policy (e.g. https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html). t-bast raised the prospect of mining pools exposing public APIs to push them transactions directly. The impact of changes to Bitcoin Core on L2 protocols Some changes to Core (e.g. some privacy improvements) can conflict with the goal of minimizing transaction propagation times. Chris_Stewart_5 raised the idea of a nightly bitcoind build to give L2 developers a way to write regression tests against the latest builds of bitcoind. He added that L2 devs should write automated regression test suites against bitcoind exposed RPC commands. t-bast would like a bitcoind “evicttx” RPC to remove a transaction from the mempool on regtest. Full RBF In advance of the workshop ariard posted to the mailing list a proposal for full RBF in a future version of Bitcoin Core: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html Progress in this direction has been attempted in the past (e.g. https://github.com/bitcoin/bitcoin/pull/10823) BlueMatt pointed out that even with full RBF it is trivial to create mempool partitions. As long as RBF has a fee rate increase minimum an attacker can trivially split the mempool by broadcasting two conflicting transactions with the same fee. ariard plans to contact businesses (e.g. Lightning onboarding services relying on zero confirmations) to check that this possible eventual move to full RBF doesn’t present a problem for them. There could well be engineering work required in advance of the possible change being made. Next week’s meeting Next week’s meeting (Tuesday 22nd June, 19:00 UTC, #l2-onchain-support, Libera) will be on fee bumping and package relay that glozow has recently been working to advance in Bitcoin Core. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Update on Taproot activation releases
I discussed in the last Taproot activation meeting notes the plans for an alternative release to Bitcoin Core with the Speedy Trial activation mechanism (BIP 8, consistent use of block height) followed by a BIP 8(1 year, LOT=true). This has now been released (version 0.1) under the name "Bitcoin Core 0.21.0-based Taproot Client". The build is available from https://bitcointaproot.cc/ and the GitHub repo is here: https://github.com/BitcoinActivation/bitcoin Luke Dashjr (Bitcoin Core contributor, Bitcoin Knots, UASF) is contributing to this release but there are a number of other pseudonymous individuals contributing to it too. In my attempted neutral stance I would say that it is not as thoroughly reviewed as an upcoming Bitcoin Core release will be but if you support a consistent use of block height (BIP 8 Speedy Trial) followed by a BIP 8 (1 year, LOT=true) I would encourage you to review and test it. Of course there may well be future version releases of "Bitcoin Core 0.21.0-based Taproot Client". If you are unable to review the code yourself but you support this effort it may be worth waiting for a future version before running it or ensuring you update to the latest version when it is released. Moving onto Bitcoin Core and other alternative Bitcoin implementations. As expected Bitcoin Core is proceeding with Speedy Trial (mix of MTP and block height, BIP to be decided). If Speedy Trial fails to activate on this Core release there is no follow up activation mechanism. That is not to say there will never be one in a Core release later in the year but as it stands there is no follow up. Bitcoin Core PR 21377 has been merged and the activation parameters (Bitcoin Core PR 21686) have also been merged. As discussed in my previous email you would expect Speedy Trial to activate (or not activate) on both Bitcoin Core and Bitcoin Core 0.21.0-based Taproot Client. However, there is a small possibility it activates on one but not the other. This is due to Bitcoin Core going with a mix of MTP and block height and Bitcoin Core 0.21.0-based Taproot Client going with consistent block height. Assuming they both activate due to Speedy Trial they share the same activation block height of 709632 (approximately November 12th 2021). If Speedy Trial fails to activate Bitcoin Core 0.21.0-based Taproot Client will attempt to enforce miner signaling in November 2022 (approximately, it is defined by block height). To be clear that is November **2022**. There are of course alternative Bitcoin implementations to Bitcoin Core. Jeremy Rubin has attempted to inform the maintainers of some alternative Bitcoin implementations of the finalized activation parameters in Core: https://github.com/bitcoin/bips/pull/1104#issuecomment-820011540 At the time of writing Laolu Osuntokun (roasbeef, maintainer of btcd) has ACKed the parameters and stated "I think we'll be able to get everything reviewed+tested (likely adding signet support along the way) by November." Piotr Narewski (maintainer of Gocoin) has also notified that he's seen the parameters. In terms of future meetings on the ##taproot-activation Freenode channel there is only one meeting currently booked. That is on Tuesday April 20th at 19:00 UTC and the meeting host will be Jeremy Rubin. The mailing list has yet to receive an agenda but I suspect it will be sent at some point in advance of the meeting. As always if there are any errors or perceived bias in my attempts to inform please respond. Ideally I would like all users to be informed of the facts so they can make up their mind on what to run and what they spend time reviewing and testing. Of course tensions are running higher than normal but that is not an excuse to spread factual inaccuracies. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Yesterday's Taproot activation meeting on IRC
Yesterday there was a Taproot activation meeting on the ##taproot-activation Freenode channel. The agenda was posted in advance to the mailing list by BitcoinMechanic. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018769.html The conversation log is here: http://gnusha.org/taproot-activation/2021-04-13.log Discussion focused on an alternative release to Bitcoin Core with the naming of the release not yet finalized. Some participants expressed concern of having "Bitcoin Core" in the name e.g. "Bitcoin Core + Taproot" as it would be confusing to users and give them the mistaken impression that it had been signed off by Bitcoin Core maintainers. The activation mechanism(s) for this alternative release is Speedy Trial (BIP 8, consistent use of block height) followed by BIP 8 (1 year, LOT=true). The BIP 8 (1 year, LOT=true) is only started assuming Taproot hasn't activated during the Speedy Trial deployment. Draft release notes for this alternative release are here: https://docs.google.com/document/d/1Uhn1SEDMAqQkzkPZ4B5lPTSjUFEXKPndt_oBI4eUm7A/edit?usp=sharing The GitHub repo for this alternative release is here: https://github.com/BitcoinActivation/bitcoin To compare this to the most likely activation mechanism(s) in Bitcoin Core at this point. If the Core PR #21377 is merged in its current form then the activation mechanism in Bitcoin Core will be Speedy Trial (BIP to be decided, mix of block height and MTP). The starttime and timeout will use MTP and the activation point will use block height. The Core PR #21377 is here: https://github.com/bitcoin/bitcoin/pull/21377 In addition a BIP PR for the Core release has been opened here with suggested finalized parameters: https://github.com/bitcoin/bips/pull/1104 If these plans continue as is Bitcoin Core and this alternative release won't be entirely compatible due to startheight and timeout being defined according to MTP and block height respectively. In the majority of cases they should both activate at the same block height (or not activate) but there are unlikely edge cases where one activates and one doesn't (in addition to a possible timewarp attack on MTP). The use of MTP in Speedy Trial for Bitcoin Core has been discussed extensively and reviewers' opinions are summarized here: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-818758277 >From this point on I will try to stay as neutral as I can and just summarize the facts to keep this list informed but anyone can review my past mailing list posts to get my personal views if you are interested. As a reminder anyone can host a meeting on the ##taproot-activation channel. All they need to do is contact me to book a time slot and ideally post an agenda to this mailing list in advance of the meeting. That meeting host will have the ability to issue warnings and if necessary kick participants if the meeting host feels they are disrupting the meeting or diverting conversation from the agenda. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC
Hi Bitcoin Mechanic I will attend but I will be looking at Core PR #21377 over the next couple of days and I would encourage other reviewers to review that PR too. If that PR is merged into Core I would strongly recommend any alternative release be fully compatible with the activation parameters in Core. We can discuss in the meeting what we think the cut off date should be for when Core should no longer be a consideration. Personally I think (and hope) we will see progress on #21377 in the coming days. For the sake of the mailing list Bitcoin Mechanic has set up a meeting to discuss an alternative release to Core with Taproot activation code. Thanks Michael > Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC > The focus of the meeting will be ratifying the Taproot activation plan > previously discussed at the March 16th meeting (aka 2021-03 Plan Y as > summarized here): https://docs.google.com/spreadsheets/d/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdEwo0PjI2NHD3w/edit#gid=0 > While there was never any consensus reached on the LOT parameter, there > appears to be consensus on BIP8 and the remaining parameters, and more than > sufficient support for LOT=True to proceed safely. > Miners will have 18 months in which to signal and accelerate activation. If > not, taproot will activate regardless. > With a majority of the economy running this it will guarantee eventual > lock-in of taproot with the smallest chance of a chain split. > As a reminder, the channel is also open for ongoing discussion 24/7, and > there is a web chat client here: > https://webchat.freenode.net/?channel=##taproot-activation > Best, > Bitcoin Mechanic > Sent with [ProtonMail](https://protonmail.com/) Secure Email. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
In my previous email in response to David Harding I said: "I think you have consistently said it doesn't matter too much although you did previously express a preference for block height." This was based on: "My preference would be for whatever solution is most preferred by reviewers." March 7th https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792220340 With a greater number of PR comments preferring block height at this point I concluded that this equated to a preference for block height. I'm happy to correct my previous statement having spoken to David. This did not equate to a preference and David was entirely neutral. For the sake of the mailing list (even though David didn't do so) expressing preferences on a PR is absolutely fine. It is fine to say "This is my preference" without NACKing a PR or NACKing a technical decision. I (and many others) have done this. Maintainers can look through the PR, read the rationales for the preferences and still consider merging the PR. However, well reasoned NACKs (e.g. Concept, Approach NACKs) make it difficult for maintainers to merge a PR especially if they are from long term contributors. If you oscillate from a preference one way to a full on NACK the other way to "Let's coin flip it" with minimal rationale you are making maintainers' jobs even more difficult. You are also wasting the time of reviewers who don't know which PR to review and which PR stands a better chance of being merged. You are also (unintentionally) increasing the risk of bugs not being caught because the PR that eventually gets merged hasn't received the review it could have. I have been criticized on IRC for the tone of my emails. To be clear I take Taproot activation seriously, I take the Core review process seriously and I take keeping the community informed of the likely timetable seriously. I'm not impressed by people wasting my time and I'm doubly not impressed by people wasting other Core reviewers' time and maintainers' time. If that informs my tone so be it. This is not directed towards David who has worked hard to make progress with Taproot activation, hasn't wasted anyone's time and I have a huge amount of respect for. In terms of the latest state of play with Core, there is an open Core PR for Speedy Trial (#21377) that appears to be our best chance of getting activation code merged into Core. The more testing and code review this Core PR receives the better. If it continues to make progress the discussion will then need to move onto a timetable. On Fri, Apr 9, 2021 at 12:19 PM Michael Folkson wrote: > > I have no problem with coin tosses to decide for example shed colors > (an illustrative example discussed by copumpkin, roasbeef on IRC). In > this kind of example everyone should recognize it doesn't matter and > Approach ACK two competing PRs. No one should be NACKing or Approach > NACKing a PR based on shed color. If the maintainers don't care about > the shed color either then they are free to use a coin toss to decide > which PR to merge. In this example there shouldn't be any NACKs, > Approach NACKs or technical opposition from regular Core reviewers. > NACKs are not meant to be used for shed colors. > > However, in this example the organizer of the coin toss had previously > NACKed one of the options (block height, though his position seems to > change by the day) and others have NACKed MTP. I think you have > consistently said it doesn't matter too much although you did > previously express a preference for block height. > > I don't want to belabor the point but can we avoid even suggesting > using coin tosses on consensus code decisions in future please? It > makes a mockery of those who spent time understanding the technical > considerations and have spent months or years working on soft fork > activations. Even in the shed color example, leave it to the > maintainers to decide whether a coin toss is appropriate rather than > creating a circus around a coin toss in a public meeting where the PR > authors weren't present and no Core maintainers were present. > > I understand the frustration and I understand the desire to break > deadlocks. But if the coin toss organizer hadn't previously NACKed one > of the options (block height) we may have avoided getting into this > deadlock in the first place. > > Your recent review notes of PR #21377 look great and are proving very > helpful to me as I look at the PR. > https://gist.github.com/harding/e622323eaf80d620826a7cb74ab3fb40 > > Thanks > Michael > > On Thu, Apr 8, 2021 at 10:57 PM David A. Harding wrote: > > > > On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev > > wrote: > > > So the latest circus
Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
I have no problem with coin tosses to decide for example shed colors (an illustrative example discussed by copumpkin, roasbeef on IRC). In this kind of example everyone should recognize it doesn't matter and Approach ACK two competing PRs. No one should be NACKing or Approach NACKing a PR based on shed color. If the maintainers don't care about the shed color either then they are free to use a coin toss to decide which PR to merge. In this example there shouldn't be any NACKs, Approach NACKs or technical opposition from regular Core reviewers. NACKs are not meant to be used for shed colors. However, in this example the organizer of the coin toss had previously NACKed one of the options (block height, though his position seems to change by the day) and others have NACKed MTP. I think you have consistently said it doesn't matter too much although you did previously express a preference for block height. I don't want to belabor the point but can we avoid even suggesting using coin tosses on consensus code decisions in future please? It makes a mockery of those who spent time understanding the technical considerations and have spent months or years working on soft fork activations. Even in the shed color example, leave it to the maintainers to decide whether a coin toss is appropriate rather than creating a circus around a coin toss in a public meeting where the PR authors weren't present and no Core maintainers were present. I understand the frustration and I understand the desire to break deadlocks. But if the coin toss organizer hadn't previously NACKed one of the options (block height) we may have avoided getting into this deadlock in the first place. Your recent review notes of PR #21377 look great and are proving very helpful to me as I look at the PR. https://gist.github.com/harding/e622323eaf80d620826a7cb74ab3fb40 Thanks Michael On Thu, Apr 8, 2021 at 10:57 PM David A. Harding wrote: > > On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev > wrote: > > So the latest circus act is apparently a technical decision made by a > > coin toss [organized by] Jeremy Rubin > > Actually, the coin toss was my idea[1], used a bash oneliner I wrote[2], > and is the same method I've been using in Bitcoin-related discussions > for over seven years[3] to help people transition from ancillary arguments > back to working on the things they really think are important. > > I proposed the coin toss because I understood that both the MTP and the > height approaches required tradeoffs that were, to a certain degree, > unresolvable to the best of our current knowledge. MTP is harder to > analyze for unexpected edge cases; heights would create extra work for > seasoned developers working on post-taproot soft forks. MTP would > require developers of currently-planned UASF software either do extra > work or wait to release their software; heights don't guarantee a > minimum amount of time for a large number of economic full nodes to > upgrade. > > Different people gave different weights to the different tradeoffs. In > cases like this where there's no known way to eliminate the tradeoffs > and no way to objectively rank them, I think it's better to begin > working on something concrete than it is to try to persuade everyone to > adopt the same subjective ranking of the tradeoffs---or, as the IETF > published in RFC7282: > > "There are times where the result of [an informal open-ended > conversation] is a pretty even split. In practical terms, that > means it doesn't matter where the chair starts the discussion. And > in fact, we've had working groups where a coin flip decided which > proposal to start with. That doesn't mean that the coin flip > determined the outcome; if a fatal technical flaw was found in the > solution that won the coin flip, it is still incumbent upon the > group to address the issue raised or abandon that solution and find > another. Rough consensus on the technical points, in the end, is > always required. Any way to find a place to start, be it the hum or > the coin flip, is only getting to the beginning of the discussion, > not the end." > > As Jeremy wrote, in this occassion, we didn't actually need the coin > toss. The authors of the two PRs we were considering found a compromise > solution that seems to be good enough for both of them and which so far > seems to be good enough for the handful of people who agreed to the coin > toss (plus, it seems, several others who didn't agree to the toss). > > In short, I think the coin toss was a good attempt. Although we didn't > use its results this time, I think it's something we should keep in our > toolkit for the futur
[bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
I will continue to update the list on the latest developments as I see them. That's all I can do. So the latest circus act is apparently a technical decision made by a coin toss. The rationale being that this discussion on using block height vs a mix of block height and MTP was bikeshedding all along. Here's a short abridged timeline on the views on block height vs MTP of the organizer (Jeremy Rubin) of that coin toss: March 8th: "I have a preference for fully height based design, correct." https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802396191 March 24th: "There are two NACKs, one (luke-jr) against MTP, one (jeremyrubin) against height.” https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018715.html April 6th: "The following folks in the meeting agreed to abide by the flip jeremyrubin" https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018742.html April 7th: "So @achow101 is correct that it is not the coin flip which made the decision." https://github.com/bitcoin/bitcoin/pull/21393#issuecomment-815388126 Please note on March 24th the only person NACKing block height in that meeting was Jeremy Rubin. He has gone from preferring block height, to NACKing block height, to thinking this discussion all along was bikeshedding and worthy of a coin flip to admitting the coin flip was theater. All of this makes me extremely uncomfortable and I dread to think what individuals and businesses all over the world who have plans to utilize and build on Taproot are making of all of this. As an individual I would like to distance myself from this circus. I will try to keep the mailing list informed though of further developments re Speedy Trial in Core or progress on an alternative client. There are two StackExchange answers here on block height vs MTP, one by David Harding and one by myself for those that are interested in the technical considerations. https://bitcoin.stackexchange.com/questions/103854/should-block-height-or-mtp-or-a-mixture-of-both-be-used-in-a-soft-fork-activatio -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
