[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
Re: [bitcoin-dev] ANYPREVOUT in place of CTV
The proposed use case for the ANYSCRIPT part of APOAS explicitly doesn't commit to amount, so I'd also assume it not be re-added or at least be able to be opened out. On Sat, Apr 30, 2022, 4:47 AM Nadav Ivgi via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi darosior, > > It's interesting to note that APOAS|SINGLE (with the ANYONECANPAY > behaviour and without covering the spent input index) has some interesting > uses for cases where the covenant only needs to restrict a single output > (so useful for e.g. vaults or spacechains, but not for batch channels or > congestion control). > > For example in the vault use-case, it makes it possible to bump fees on > the unvault tx by adding more inputs and a change output, as well as > unvault multiple vaulted outputs in a single transaction. > > For spacechains, it makes it possible to add the spaceblock hash OP_RETURN > and pay fees directly in the tx chain, instead of having to use an > additional tx to prepare an output that gets spent in the tx chain (see > the diagram in [0]). > > > via `sha_sequences` and maybe also `sha_amounts` > > CTV does not commit to the input amounts. This has some practical > implications: > > 1. If it is committed, sending an even slightly incorrect amount will make > the covenant-encumbered spend path unusable. > > With CTV, sending a slightly lower amount results in slightly lower fees, > while any extra gets spent/burned on fees. The covenant spend path only > becomes unusable if the amount is too low to cover for the outputs (+relay > fee for it to also be standard). > > 2. The ability to allow for additional inputs with unknown amounts makes > it possible to fee-bump the covenant spending transaction (with whole utxos > and no change). You can have one tapleaf for spending the covenant output > alone, and another one for attaching an extra fee input to it. > > This also makes it possible to resolve the under-payment issue described > in (1), by adding an input that covers the original intended amount. > > So my suggestion would be to either not cover `sha_amounts` in the msg > hash, or to make it optional behind a flag. > > shesek > > [0] https://github.com/fiatjaf/simple-ctv-spacechain > > On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I would like to know people's sentiment about doing (a very slightly >> tweaked version of) BIP118 in place of >> (or before doing) BIP119. >> >> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for >> over 6 years. It presents proven and >> implemented usecases, that are demanded and (please someone correct me if >> i'm wrong) more widely accepted than >> CTV's. >> >> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made >> optional [0], can emulate CTV just fine. >> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more >> expensive to use. But we can consider CTV >> an optimization of APO-AS covenants. >> >> CTV advocates have been presenting vaults as the flagship usecase. >> Although as someone who've been trying to >> implement practical vaults for the past 2 years i doubt CTV is necessary >> nor sufficient for this (but still >> useful!), using APO-AS covers it. And it's not a couple dozen more >> virtual bytes that are going to matter for >> a potential vault user. >> >> If after some time all of us who are currently dubious about CTV's stated >> usecases are proven wrong by onchain >> usage of a less efficient construction to achieve the same goal, we could >> roll-out CTV as an optimization. In >> the meantime others will have been able to deploy new applications >> leveraging ANYPREVOUT (Eltoo, blind >> statechains, etc..[1]). >> >> >> Given the interest in, and demand for, both simple covenants and better >> offchain protocols it seems to me that >> BIP118 is a soft fork candidate that could benefit more (if not most of) >> Bitcoin users. >> Actually i'd also be interested in knowing if people would oppose the >> APO-AS part of BIP118, since it enables >> CTV's features, for the same reason they'd oppose BIP119. >> >> >> [0] That is, to not commit to the other inputs of the transaction (via >> `sha_sequences` and maybe also >> `sha_amounts`). Cf >> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message >> . >> >> [1] https://anyprevout.xyz/ "Use Cases" section >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] ANYPREVOUT in place of CTV
Hi darosior, It's interesting to note that APOAS|SINGLE (with the ANYONECANPAY behaviour and without covering the spent input index) has some interesting uses for cases where the covenant only needs to restrict a single output (so useful for e.g. vaults or spacechains, but not for batch channels or congestion control). For example in the vault use-case, it makes it possible to bump fees on the unvault tx by adding more inputs and a change output, as well as unvault multiple vaulted outputs in a single transaction. For spacechains, it makes it possible to add the spaceblock hash OP_RETURN and pay fees directly in the tx chain, instead of having to use an additional tx to prepare an output that gets spent in the tx chain (see the diagram in [0]). > via `sha_sequences` and maybe also `sha_amounts` CTV does not commit to the input amounts. This has some practical implications: 1. If it is committed, sending an even slightly incorrect amount will make the covenant-encumbered spend path unusable. With CTV, sending a slightly lower amount results in slightly lower fees, while any extra gets spent/burned on fees. The covenant spend path only becomes unusable if the amount is too low to cover for the outputs (+relay fee for it to also be standard). 2. The ability to allow for additional inputs with unknown amounts makes it possible to fee-bump the covenant spending transaction (with whole utxos and no change). You can have one tapleaf for spending the covenant output alone, and another one for attaching an extra fee input to it. This also makes it possible to resolve the under-payment issue described in (1), by adding an input that covers the original intended amount. So my suggestion would be to either not cover `sha_amounts` in the msg hash, or to make it optional behind a flag. shesek [0] https://github.com/fiatjaf/simple-ctv-spacechain On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I would like to know people's sentiment about doing (a very slightly > tweaked version of) BIP118 in place of > (or before doing) BIP119. > > SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for > over 6 years. It presents proven and > implemented usecases, that are demanded and (please someone correct me if > i'm wrong) more widely accepted than > CTV's. > > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made > optional [0], can emulate CTV just fine. > Sure then you can't have bare or Segwit v0 CTV, and it's a bit more > expensive to use. But we can consider CTV > an optimization of APO-AS covenants. > > CTV advocates have been presenting vaults as the flagship usecase. > Although as someone who've been trying to > implement practical vaults for the past 2 years i doubt CTV is necessary > nor sufficient for this (but still > useful!), using APO-AS covers it. And it's not a couple dozen more virtual > bytes that are going to matter for > a potential vault user. > > If after some time all of us who are currently dubious about CTV's stated > usecases are proven wrong by onchain > usage of a less efficient construction to achieve the same goal, we could > roll-out CTV as an optimization. In > the meantime others will have been able to deploy new applications > leveraging ANYPREVOUT (Eltoo, blind > statechains, etc..[1]). > > > Given the interest in, and demand for, both simple covenants and better > offchain protocols it seems to me that > BIP118 is a soft fork candidate that could benefit more (if not most of) > Bitcoin users. > Actually i'd also be interested in knowing if people would oppose the > APO-AS part of BIP118, since it enables > CTV's features, for the same reason they'd oppose BIP119. > > > [0] That is, to not commit to the other inputs of the transaction (via > `sha_sequences` and maybe also > `sha_amounts`). Cf > https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message > . > > [1] https://anyprevout.xyz/ "Use Cases" section > ___ > 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] Towards a means of measuring user support for Soft Forks
Good morning Billy, > @Zman > > if two people are perfectly rational and start from the same information, > > they *will* agree > I take issue with this. I view the word "rational" to mean basically logical. > Someone is rational if they advocate for things that are best for them. Two > humans are not the same people. They have different circumstances and as a > result different goals. Two actors with different goals will inevitably have > things they rationally and logically disagree about. There is no universal > rationality. Even an AI from outside space and time is incredibly likely to > experience at least some value drift from its peers. Note that "the goal of this thing" is part of the information where both "start from" here. Even if you and I have different goals, if we both think about "given this goal, and these facts, is X the best solution available?" we will both agree, though our goals might not be the same as each other, or the same as "this goal" is in the sentence. What is material is simply that the laws of logic are universal and if you include the goal itself as part of the question, you will reach the same conclusion --- but refuse to act on it (and even oppose it) because the goal is not your own goal. E.g. "What is the best way to kill a person without getting caught?" will probably have us both come to the same broad conclusion, but I doubt either of us has a goal or sub-goal to kill a person. That is: if you are perfectly rational, you can certainly imagine a "what if" where your goal is different from your current goal and figure out what you would do ***if*** that were your goal instead. Is that better now? > > 3. Can we actually have the goals of all humans discussing this topic all > > laid out, *accurately*? > I think this would be a very useful exercise to do on a regular basis. This > conversation is a good example, but conversations like this are rare. I tried > to discuss some goals we might want bitcoin to have in a paper I wrote about > throughput bottlenecks. Coming to a consensus around goals, or at very least > identifying various competing groupings of goals would be quite useful to > streamline conversations and to more effectively share ideas. Using a future market has the attractive property that, since money is often an instrumental sub-goal to achieve many of your REAL goals, you can get reasonably good information on the goals of people without them having to actually reveal their actual goals. Also, irrationality on the market tends to be punished over time, and a human who achieves better-than-human rationality can gain quite a lot of funds on the market, thus automatically re-weighing their thoughts higher. However, persistent irrationalities embedded in the design of the human mind will still be difficult to break (it is like a program attempting to escape a virtual machine). And an uninformed market is still going to behave pretty much randomly. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
