Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors
Are there any plans other than `raw` to support time locks in descriptors? Any plans for descriptors offering closer integration with miniscript? All of Blockchain Commons libraries and tools are multisig descriptor centric, and there are many scenarios that require describing time locks: - [Designing Multisig for Independence & Resilience]( https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Multisig.md ) — Christopher Allen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors
On 6/29/21 6:22 PM, Christopher Allen wrote: > Are there any plans other than `raw` to support time locks in descriptors? > > Any plans for descriptors offering closer integration with miniscript? I expect miniscript to be a followup BIP that extends these descriptors. Miniscript has timelock functionality. Andrew > All of Blockchain Commons libraries and tools are multisig descriptor > centric, and there are many scenarios that require describing time locks: > > - [Designing Multisig for Independence & > Resilience](https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Multisig.md) > > — Christopher Allen___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
Good morning Raymo, > Hey Alex, > > Your scenario works perfectly unless we put some restrictions on > accepting transaction by creditor (in our case Bob). > These are restrictions: > Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as > transaction input. > Alice has to reserve 10,000 Sat as transaction fee (for MT transaction) > regardless of transaction length or input/output amounts. > Alice always pays at least 4,000 Sat of BTC-transaction-fee, and the > 6,000 remined fee must be paid by she and Bob in proportion to their > outputs amounts) > Alice can issue a transaction the has maximum 20,000 outputs for > creditors (Bob and others). > The rest (if exist) is change back to Alice address. > The GT is formed based on MT. > Bob considers a transaction couple (MT, GT) valid only if they respect > these rules. > > Let’s put it in practice using some numbers (although you can find more > detailed explanation in paper). > > The MT would be like that: > Input: 40,000 Satoshi > Outputs: > Bob: 20,000 > BTC-fee: 10,000 > Change back to Alice: 10,000 > > Based on this MT the GT will be > Input: 40,000 Satoshi > Outputs: > Bob: 20,000 – 20,00070% = 6,000 > BTC-fee: 10,000 + (14,000 of Bob’s output) + (1,500 of Alice’s change > back) = 25,500 > Change back to Alice: 10,000 – 10,00015% = 8,500 > > Now if Alice wants to spend UTXO to Charlie with higher fee, she has to > pay at least 25,500 + 1 Satoshi as BTC fee in order to convince miners > to put his fraudulent transaction instead the GT in next block. > Alice already got 20,000 Sat profit from Bob. Now she can earn another > 14,999 Sat profit from Charlie because of same UTXO worth 40,000 > Satoshi. > Indeed, she spent 40,000 Sat and in total got equal to 34,999 Sat goods > or services. > Is she a winner? > I am not sure! > What do you think? You assume here that Alice the issuer only has a single UTXO and that it creates a single transaction spending that UTXO. It is helpful to remember that miners consider fee*rate*, but your security analysis is dependent on *fee* and not fee*rate*. Now consider, what if Alice creates 1000 UTXOs, promises GTs and MTs to 1000 different Bobs? Now, a GT has one input and two outputs. 1000 GTs have 1000 overheads (`nLockTime` and `nVersion` and so on), 1000 inputs, and 2000 outputs. Now Alice the issuer, being the sole signer, can create a fraudulent transaction that spends all 1000 UTXOs and spends it to a single Carol output. This fraudulent transaction has 1 overhead, 1000 inputs, and 1 output. Do you think Alice can get a better fee*rate* on that transaction while paying a lower aggregate *fee* than all the GTs combined? Remember, you based your security analysis on Alice being forced to pay a larger *fee*, but neglect that miners judge transactions based on fee*rate*, which is subtly different and not what you are relying on. I am sure that there exists some large enough number of UTXOs where a single aggregating fraudulent transaction will be far cheaper than the tons of little GTs your security analysis depends on. This is why we do not use 1-of-1 signers in safe offchain protocols. Not your keys, not your coins. -- In addition, your analysis is based on assuming that miners are perfect rational beings of perfect rationality, ***and*** are omniscient. In reality, miners possess bounded knowledge, i.e. they do not know everything. Even if Alice is in possession of only a single UTXO, Alice can still feed miners a transaction with lower feerate than the MT, then feed the rest of the network with a valid MT. Because transactions propagate through the network but this propagation is ***not*** instantaneous, it is possible for the MT to reach the miners later than the fraudulent transaction. In this window of time, a block may be mined that includes the fraudulent transaction, simply because the lucky miner never managed to hear of the correct MT. This attack is essentially costless to Alice, especially for big enough transactions where mining fees are a negligible part of the payment. This is why we do not use 1-of-1 signers in safe offchain protocols. Not your keys, not your coins. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
> On Jun 29, 2021, at 12:28, Jorge Timón wrote: > > > "Confirmation" isn't needed for softforks. All transactions require confirmation. Splitting does not change this. Softforks are not compatible without miner enforcement. So soft forking without it has essentially the same effect as hard forking, the chain splits. > Miners controlling confirmation doesn't mean miners control the rules, they > never did. Please define “control” because these statements hinge on that word. Nobody “controls” the rules of others, nor did anyone claim that to be the case. Majority hash power does have the ability to determine what gets confirmed. That is the central design principle of proof of work. It takes that decision out of the hands of politicians and places it at the feet of the market. > Read section 11 of the bitcoin paper "even with a majority of hashrate one > cannot arbitrarily change rules or forge signatures. Never claimed that was the case. One can run any rules that one desires. > You may say users chosing the rules is "politicial". Isn't miners deciding > them for users more political? No, it’s economic. The largest investment in mining (including highest fees paid to incentivize it) determines censorship resistance. > Whatever you call it, it is still how free software works: users decide what > to run. A *person* can run whatever software they want. Money requires that others agree (same rules), and to be money bitcoin requires confirmation. > It is extremely disappointing to see how few developers seem to ubderstand > this, or even care about users deciding or miners not deciding the rules. It’s poorly understood because there are so many who should know better making very misleading statements. > How can we expect users to understand bitcoin when most developers don't seem > to understand it? Clearly we cannot. > It is really sad. > >> On Tue, Jun 29, 2021, 19:17 Eric Voskuil wrote: >> >> > On Jun 29, 2021, at 10:55, Luke Dashjr wrote: >> > >> > The only alternative to a split in the problematic scenarios are 1) >> > concede >> > centralised miner control over the network, >> >> Miners control confirmation, entirely. >> >> This is the nature of bitcoin. And merchants control validation, entirely. >> Anyone can be a miner or a merchant. Neither is inherently “better” than the >> other. The largest merchants are likely a handful of exchanges, likely at >> least as centralized as miners are pooled. >> >> Splitting does not change this. >> >> > and 2) have inconsistent >> > enforcement of rules by users who don't agree on what the correct rules >> > are, >> >> There are no “correct” rules. Whatever rules one enforces determine what >> network he chooses to participate in. >> >> > again leading to centralised miner control over the network. >> >> Leading to? Miners control confirmation, always. Whether that is >> centralized, just as with merchanting, is up to individuals. >> >> > In other words, in this context, accepting a split between disagreeing >> > users >> > is the ONLY way Bitcoin can possibly continue as a decentralised currency. >> >> No, it is not. You are proposing splitting as the method of censorship >> resistance inherent to Bitcoin. Coordinating this split requires coordinated >> action. The whole point of bitcoin is coordinate that action based on mining >> (proof of work). Replacing that with a political process is just a reversion >> to political money. >> >> > Making that split as clean and well-defined as possible not only ensures >> > the >> > best opportunity for both sides of the disagreement, >> >> Trivially accomplished, just change a rule. This isn’t about that. It’s >> about how one gets others to go along with the new coin, or stay with the >> old. An entirely political process, which is clearly evident from the >> campaigns around such attempts. >> >> > but also minimises the >> > risk that the split occurs at all (since the "losing" side needs to >> > concede, >> > rather than passively continue the disagreement ongoing after the >> > attempted >> > protocol change). >> >> Nobody “needs to” concede once a split has occurred, which is evident in >> existing splits. >> >> e >> >> > Luke >> > >> > >> >> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote: >> >> At least we are now acknowledging that splitting is what it’s about. >> >> That’s >> >> progress. >> >> >> >> e >> >> >> On Jun 29, 2021, at 01:32, Jorge Timón wrote: >> >>> >> >>> >> >>> I think the option of "permanent failure because miners veto" should >> >>> actually be abandoned. No, I don't think we should avoid splits when >> >>> possible, I don't think we should avoid splits at all costs. >> >>> >> On Sun, Jun 27, 2021, 19:12 Billy Tetrud wrote: >> @Luke >> >> > They can still slow it down. >> >> Absolutely. However I think that the option of permanent failure is >> important. It cer
Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
"Confirmation" isn't needed for softforks. Miners controlling confirmation doesn't mean miners control the rules, they never did. Read section 11 of the bitcoin paper "even with a majority of hashrate one cannot arbitrarily change rules or forge signatures. You may say users chosing the rules is "politicial". Isn't miners deciding them for users more political? Whatever you call it, it is still how free software works: users decide what to run. It is extremely disappointing to see how few developers seem to ubderstand this, or even care about users deciding or miners not deciding the rules. How can we expect users to understand bitcoin when most developers don't seem to understand it? It is really sad. On Tue, Jun 29, 2021, 19:17 Eric Voskuil wrote: > > > On Jun 29, 2021, at 10:55, Luke Dashjr wrote: > > > > The only alternative to a split in the problematic scenarios are 1) > concede > > centralised miner control over the network, > > Miners control confirmation, entirely. > > This is the nature of bitcoin. And merchants control validation, entirely. > Anyone can be a miner or a merchant. Neither is inherently “better” than > the other. The largest merchants are likely a handful of exchanges, likely > at least as centralized as miners are pooled. > > Splitting does not change this. > > > and 2) have inconsistent > > enforcement of rules by users who don't agree on what the correct rules > are, > > There are no “correct” rules. Whatever rules one enforces determine what > network he chooses to participate in. > > > again leading to centralised miner control over the network. > > Leading to? Miners control confirmation, always. Whether that is > centralized, just as with merchanting, is up to individuals. > > > In other words, in this context, accepting a split between disagreeing > users > > is the ONLY way Bitcoin can possibly continue as a decentralised > currency. > > No, it is not. You are proposing splitting as the method of censorship > resistance inherent to Bitcoin. Coordinating this split requires > coordinated action. The whole point of bitcoin is coordinate that action > based on mining (proof of work). Replacing that with a political process is > just a reversion to political money. > > > Making that split as clean and well-defined as possible not only ensures > the > > best opportunity for both sides of the disagreement, > > Trivially accomplished, just change a rule. This isn’t about that. It’s > about how one gets others to go along with the new coin, or stay with the > old. An entirely political process, which is clearly evident from the > campaigns around such attempts. > > > but also minimises the > > risk that the split occurs at all (since the "losing" side needs to > concede, > > rather than passively continue the disagreement ongoing after the > attempted > > protocol change). > > Nobody “needs to” concede once a split has occurred, which is evident in > existing splits. > > e > > > Luke > > > > > >> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote: > >> At least we are now acknowledging that splitting is what it’s about. > That’s > >> progress. > >> > >> e > >> > On Jun 29, 2021, at 01:32, Jorge Timón wrote: > >>> > >>> > >>> I think the option of "permanent failure because miners veto" should > >>> actually be abandoned. No, I don't think we should avoid splits when > >>> possible, I don't think we should avoid splits at all costs. > >>> > On Sun, Jun 27, 2021, 19:12 Billy Tetrud > wrote: > @Luke > > > They can still slow it down. > > Absolutely. However I think that the option of permanent failure is > important. It certainly would be ideal to ensure that enough bitcoin > users support the upgrade *before* releasing it, however realistically > this can never be more than an estimate, and estimates can sometimes > be > wildly wrong. It would be unfortunate if miners had a substantially > different estimate of user support than the people putting in the work > to release bitcoin upgrades. Even if upgrades are never released > before > it becomes clear that a large supermajority of users want the upgrade, > if miners don't agree with the estimate a harmful chain split could > occur. And I agree with Eric that the goal here is to prevent a chain > split during an upgrade when possible. This includes permanent failure > of an upgrade when there is unexpectedly large miner opposition. > > This of course does not prevent a UASF-style deployment to be done > after > an initial failure to deploy occurs. My proposal is essentially a > mechanism to improve upon the speedy-trial idea, allowing for even > speedier releases (than speedy trial) without adding additional risk > of > undesired chain splits. > > > [BIP8] already has the trinary state you seem to be describing > > It sounds like you're saying the trinary state of BIP8 is A. Follow > t
[bitcoin-dev] BIP Proposals for Output Script Descriptors
Hi All, I've been working on formalizing the Output Script Descriptors that have been available in Bitcoin Core for a while into BIPs. Since descriptors are modular and have optional components, I've decided to split it into 7 BIPs, rather than a single one. The first describes descriptors in general and does not specify any particular descriptor. However it does describe the general operation, key expressions (including derivation paths and key origin info), and the descriptor checksum. The following 6 BIPs specify the actual descriptors themselves. These are non-segwit descriptor (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), the taproot descriptor (tr), the combo descriptor, and opaque descriptors (raw, addr). This separation is so that implementors can choose to not implement some descriptors and still say which descriptors they support without being too difficult to understand. The text of all of the documents are below, and they can also be found on github:https://github.com/achow101/bips/tree/descriptors/ Thanks, Andrew Chow --- BIP: bip-descriptors-general Layer: Applications Title: Output Script Descriptors General Operation Author: Pieter Wuille Andrew Chow Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-general Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause ==Abstract== Output Script Descriptors are a simple language which can be used to describe collections ofoutput scripts. There can be many different descriptor fragments and functions. This document describes the general syntax for descriptors, descriptor checksums, and common expressions. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Motivation== Bitcoin wallets traditionally have stored a set of keys which are later serialized and mutated to produce the output scripts that the wallet watches and the addresses it provides to users. Typically backups have consisted of solely the private keys, nowadays primarily in the form of BIP 39 mnemonics. However this backup solution is insuffient, especially since the introduction of Segregated Witness which added new output types. Given just the private keys, it is not possible for restored wallets to know which kinds of output scripts and addresses to produce. This has lead to incompatibilities between wallets when restoring a backup or exporting data for a watch only wallet. Further complicating matters are BIP 32 derivation paths. Although BIPs 44, 49, and 84 have specified standard BIP 32 derivation paths for different output scripts and addresses, not all wallets support them nor use those derivation paths. The lack of derivation path information in these backups and exports leads to further incompatibilities between wallets. Current solutions to these issues have not been generic and can be viewed as being layer violations. Solutions such as introducing different version bytes for extended key serialization both are a layer violation (key derivation should be separate from script type meaning) and specific only to a particular derivation path and script type. Output Script Descriptors introduces a generic solution to these issues. Script types are specified explicitly through the use of Script Expressions. Key derivation paths are specified explicitly in Key Expressions. These allow for creating wallet backups and exports which specify the exact scripts, subscripts (redeemScript, witnessScript, etc.), and keys to produce. With the general structure specified in this BIP, new Script Expressions can be introduced as new script types are added. Lastly, the use of common terminology and existing standards allow for Output Script Descriptors to be engineer readable so that the results can be understood at a glance. ==Specification== Descriptors consist of several types of expressions. The top level expression is a SCRIPT. This expression may be followed by #CHECKSUM, where CHECKSUM is an 8 character alphanumeric descriptor checksum. ===Script Expressions=== Script Expressions (denoted SCRIPT) are expressions which correspond directly with a Bitcoin script. These expressions are written as functions and take arguments. Such expressions have a script template which is filled with the arguments correspondingly. Expressions are written with a human readable identifier string with the arguments enclosed with parentheses. The identifier string should be alphanumeric and may include underscores. The arguments to a script expression are defined by that expression itself. They could be a script expression, a key expression, or some other expression entirely. ===Key Expressions=== A common expression used as an argument to script expressions are key expressions (denoted KEY). These represent a public or private key and, optionally, information about the origin of that key. Key expressions ca
Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
> On Jun 29, 2021, at 10:55, Luke Dashjr wrote: > > The only alternative to a split in the problematic scenarios are 1) concede > centralised miner control over the network, Miners control confirmation, entirely. This is the nature of bitcoin. And merchants control validation, entirely. Anyone can be a miner or a merchant. Neither is inherently “better” than the other. The largest merchants are likely a handful of exchanges, likely at least as centralized as miners are pooled. Splitting does not change this. > and 2) have inconsistent > enforcement of rules by users who don't agree on what the correct rules are, There are no “correct” rules. Whatever rules one enforces determine what network he chooses to participate in. > again leading to centralised miner control over the network. Leading to? Miners control confirmation, always. Whether that is centralized, just as with merchanting, is up to individuals. > In other words, in this context, accepting a split between disagreeing users > is the ONLY way Bitcoin can possibly continue as a decentralised currency. No, it is not. You are proposing splitting as the method of censorship resistance inherent to Bitcoin. Coordinating this split requires coordinated action. The whole point of bitcoin is coordinate that action based on mining (proof of work). Replacing that with a political process is just a reversion to political money. > Making that split as clean and well-defined as possible not only ensures the > best opportunity for both sides of the disagreement, Trivially accomplished, just change a rule. This isn’t about that. It’s about how one gets others to go along with the new coin, or stay with the old. An entirely political process, which is clearly evident from the campaigns around such attempts. > but also minimises the > risk that the split occurs at all (since the "losing" side needs to concede, > rather than passively continue the disagreement ongoing after the attempted > protocol change). Nobody “needs to” concede once a split has occurred, which is evident in existing splits. e > Luke > > >> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote: >> At least we are now acknowledging that splitting is what it’s about. That’s >> progress. >> >> e >> On Jun 29, 2021, at 01:32, Jorge Timón wrote: >>> >>> >>> I think the option of "permanent failure because miners veto" should >>> actually be abandoned. No, I don't think we should avoid splits when >>> possible, I don't think we should avoid splits at all costs. >>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud wrote: @Luke > They can still slow it down. Absolutely. However I think that the option of permanent failure is important. It certainly would be ideal to ensure that enough bitcoin users support the upgrade *before* releasing it, however realistically this can never be more than an estimate, and estimates can sometimes be wildly wrong. It would be unfortunate if miners had a substantially different estimate of user support than the people putting in the work to release bitcoin upgrades. Even if upgrades are never released before it becomes clear that a large supermajority of users want the upgrade, if miners don't agree with the estimate a harmful chain split could occur. And I agree with Eric that the goal here is to prevent a chain split during an upgrade when possible. This includes permanent failure of an upgrade when there is unexpectedly large miner opposition. This of course does not prevent a UASF-style deployment to be done after an initial failure to deploy occurs. My proposal is essentially a mechanism to improve upon the speedy-trial idea, allowing for even speedier releases (than speedy trial) without adding additional risk of undesired chain splits. > [BIP8] already has the trinary state you seem to be describing It sounds like you're saying the trinary state of BIP8 is A. Follow the longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded chain. I agree. However the trinary state in my proposal is materially different - it is the signaling itself that is trinary, not just which chain is being followed. This allows others to know and make programmatic decisions (in software) based on that signaling. I'm sure you can agree that does not exist in BIP8. > No additional bit is needed, as softforks are coordinated between > users, NOT miners And yet there is miner involvement, as you rightly pointed out. Miners are needed to set the nVersion in the header. So when you say "no additional bit is needed", could you please be clearer as to what you mean? Do you mean that signaling of opposition in a block can be done without any "additional bit"? Or are you just saying that it is redundant to consider what miners
Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
The only alternative to a split in the problematic scenarios are 1) concede centralised miner control over the network, and 2) have inconsistent enforcement of rules by users who don't agree on what the correct rules are, again leading to centralised miner control over the network. In other words, in this context, accepting a split between disagreeing users is the ONLY way Bitcoin can possibly continue as a decentralised currency. Making that split as clean and well-defined as possible not only ensures the best opportunity for both sides of the disagreement, but also minimises the risk that the split occurs at all (since the "losing" side needs to concede, rather than passively continue the disagreement ongoing after the attempted protocol change). Luke On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote: > At least we are now acknowledging that splitting is what it’s about. That’s > progress. > > e > > > On Jun 29, 2021, at 01:32, Jorge Timón wrote: > > > > > > I think the option of "permanent failure because miners veto" should > > actually be abandoned. No, I don't think we should avoid splits when > > possible, I don't think we should avoid splits at all costs. > > > >> On Sun, Jun 27, 2021, 19:12 Billy Tetrud wrote: > >> @Luke > >> > >> > They can still slow it down. > >> > >> Absolutely. However I think that the option of permanent failure is > >> important. It certainly would be ideal to ensure that enough bitcoin > >> users support the upgrade *before* releasing it, however realistically > >> this can never be more than an estimate, and estimates can sometimes be > >> wildly wrong. It would be unfortunate if miners had a substantially > >> different estimate of user support than the people putting in the work > >> to release bitcoin upgrades. Even if upgrades are never released before > >> it becomes clear that a large supermajority of users want the upgrade, > >> if miners don't agree with the estimate a harmful chain split could > >> occur. And I agree with Eric that the goal here is to prevent a chain > >> split during an upgrade when possible. This includes permanent failure > >> of an upgrade when there is unexpectedly large miner opposition. > >> > >> This of course does not prevent a UASF-style deployment to be done after > >> an initial failure to deploy occurs. My proposal is essentially a > >> mechanism to improve upon the speedy-trial idea, allowing for even > >> speedier releases (than speedy trial) without adding additional risk of > >> undesired chain splits. > >> > >> > [BIP8] already has the trinary state you seem to be describing > >> > >> It sounds like you're saying the trinary state of BIP8 is A. Follow the > >> longest chain, B. Follow the upgrade chain, or C. follow the > >> non-upgraded chain. I agree. However the trinary state in my proposal is > >> materially different - it is the signaling itself that is trinary, not > >> just which chain is being followed. This allows others to know and make > >> programmatic decisions (in software) based on that signaling. I'm sure > >> you can agree that does not exist in BIP8. > >> > >> > No additional bit is needed, as softforks are coordinated between > >> > users, NOT miners > >> > >> And yet there is miner involvement, as you rightly pointed out. Miners > >> are needed to set the nVersion in the header. So when you say "no > >> additional bit is needed", could you please be clearer as to what you > >> mean? Do you mean that signaling of opposition in a block can be done > >> without any "additional bit"? Or are you just saying that it is > >> redundant to consider what miners might be opposing an upgrade? > >> > >> @Jorge > >> > >> > If different users want different incompatible things... there's no > >> > way to avoid the split > >> > >> I agree. This happened with bcash, and that's fine. It was painful, but > >> there were a significant amount of users that disagreed, and they have > >> the chain they want now. > >> > >> But we generally all want to avoid a chain split when possible. Because > >> chain splits have a cost, and that cost can be high, its likely that > >> many users would rather choose the chain with the most support rather > >> than choosing the chain with their preferred rules. > >> > >> However, the question here is: how do we estimate what fraction of users > >> wants which rules? We don't have a divining rod to determine with > >> certainty what users want. We can only make polls of various levels of > >> inaccuracy. The methods bitcoin has been using is community discussion > >> and social consensus estimation as well as miner signaling during the > >> actual deployment period. Neither of these are perfect, but they are > >> both reasonable enough mechanisms. However, because both of these > >> mechanisms are very rough estimates of user sentiment, we need to > >> consider the possibility that sometimes the estimate may be > >> substantially inaccurate when we design deployment procedures. Th
[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] BIP proposal: Anti-fee-sniping protection with nSequence in taproot transactions to improve privacy for off-chain protocols
Good thinking. Your point also applies to CoinJoins (both equal-output and payjoin), and to any transaction where multiple parties contribute inputs. The BIP should say "at least one of the inputs of the transaction" with a suggestion that on-chain wallets just randomly pick an input. On 28/06/2021 11:55, Ben Carman via bitcoin-dev wrote: >> If nSequence is set it should apply only to the first input of the > transaction, if it has multiple inputs. > > This could have complications with DLCs and dual funded lightning. In both > protocols the ordering of the inputs is not know until both parties have > revealed all of their inputs, and during the reveal the nSequence is given. > If we want DLCs and dual funded lightning to be compatible it would be better > to have it define it as “at least one of the inputs of the transaction” > instead of “it should apply only to the first input of the transaction” > > benthecarman > > > > ___ > 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] Trinary Version Signaling for softfork upgrades
At least we are now acknowledging that splitting is what it’s about. That’s progress. e > On Jun 29, 2021, at 01:32, Jorge Timón wrote: > > > I think the option of "permanent failure because miners veto" should actually > be abandoned. > No, I don't think we should avoid splits when possible, I don't think we > should avoid splits at all costs. > > >> On Sun, Jun 27, 2021, 19:12 Billy Tetrud wrote: >> @Luke >> > They can still slow it down. >> >> Absolutely. However I think that the option of permanent failure is >> important. It certainly would be ideal to ensure that enough bitcoin users >> support the upgrade *before* releasing it, however realistically this can >> never be more than an estimate, and estimates can sometimes be wildly wrong. >> It would be unfortunate if miners had a substantially different estimate of >> user support than the people putting in the work to release bitcoin >> upgrades. Even if upgrades are never released before it becomes clear that a >> large supermajority of users want the upgrade, if miners don't agree with >> the estimate a harmful chain split could occur. And I agree with Eric that >> the goal here is to prevent a chain split during an upgrade when possible. >> This includes permanent failure of an upgrade when there is unexpectedly >> large miner opposition. >> >> This of course does not prevent a UASF-style deployment to be done after an >> initial failure to deploy occurs. My proposal is essentially a mechanism to >> improve upon the speedy-trial idea, allowing for even speedier releases >> (than speedy trial) without adding additional risk of undesired chain >> splits. >> >> > [BIP8] already has the trinary state you seem to be describing >> >> It sounds like you're saying the trinary state of BIP8 is A. Follow the >> longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded >> chain. I agree. However the trinary state in my proposal is materially >> different - it is the signaling itself that is trinary, not just which chain >> is being followed. This allows others to know and make programmatic >> decisions (in software) based on that signaling. I'm sure you can agree that >> does not exist in BIP8. >> >> > No additional bit is needed, as softforks are coordinated between users, >> > NOT miners >> >> And yet there is miner involvement, as you rightly pointed out. Miners are >> needed to set the nVersion in the header. So when you say "no additional bit >> is needed", could you please be clearer as to what you mean? Do you mean >> that signaling of opposition in a block can be done without any "additional >> bit"? Or are you just saying that it is redundant to consider what miners >> might be opposing an upgrade? >> >> @Jorge >> > If different users want different incompatible things... there's no way to >> > avoid the split >> >> I agree. This happened with bcash, and that's fine. It was painful, but >> there were a significant amount of users that disagreed, and they have the >> chain they want now. >> >> But we generally all want to avoid a chain split when possible. Because >> chain splits have a cost, and that cost can be high, its likely that many >> users would rather choose the chain with the most support rather than >> choosing the chain with their preferred rules. >> >> However, the question here is: how do we estimate what fraction of users >> wants which rules? We don't have a divining rod to determine with certainty >> what users want. We can only make polls of various levels of inaccuracy. The >> methods bitcoin has been using is community discussion and social consensus >> estimation as well as miner signaling during the actual deployment period. >> Neither of these are perfect, but they are both reasonable enough >> mechanisms. However, because both of these mechanisms are very rough >> estimates of user sentiment, we need to consider the possibility that >> sometimes the estimate may be substantially inaccurate when we design >> deployment procedures. This inaccuracy is why we need multiple barriers in >> place for an upgrade, and why we need to have higher thresholds of success >> (require larger supermajorities in both consensus and miner signaling). >> >> Developers obviously care about bitcoin and have an incentive (personal and >> probably financial) to do it right. And miners have both an incentive to >> keep the system healthy, as well as an incentive to mine on the chain that >> the economic majority of users is using. But measuring the consensus of the >> bitcoin community can be extraordinarily difficult to do with consistent >> accuracy, and so I think miner signaling as it has been used as a second >> barrier to entry for an upgrade is quite appropriate. >> >>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil wrote: >>> I have not objected to anyone splitting. As I said, a split is always >>> possible, and of course has been done on a large
Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
I think the option of "permanent failure because miners veto" should actually be abandoned. No, I don't think we should avoid splits when possible, I don't think we should avoid splits at all costs. On Sun, Jun 27, 2021, 19:12 Billy Tetrud wrote: > @Luke > > They can still slow it down. > > Absolutely. However I think that the option of permanent failure is > important. It certainly would be ideal to ensure that enough bitcoin users > support the upgrade *before* releasing it, however realistically this can > never be more than an estimate, and estimates can sometimes be wildly > wrong. It would be unfortunate if miners had a substantially different > estimate of user support than the people putting in the work to release > bitcoin upgrades. Even if upgrades are never released before it becomes > clear that a large supermajority of users want the upgrade, if miners don't > agree with the estimate a harmful chain split could occur. And I agree with > Eric that the goal here is to prevent a chain split during an upgrade when > possible. This includes permanent failure of an upgrade when there is > unexpectedly large miner opposition. > > This of course does not prevent a UASF-style deployment to be done after > an initial failure to deploy occurs. My proposal is essentially a mechanism > to improve upon the speedy-trial idea, allowing for even speedier releases > (than speedy trial) without adding additional risk of undesired chain > splits. > > > [BIP8] already has the trinary state you seem to be describing > > It sounds like you're saying the trinary state of BIP8 is A. Follow the > longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded > chain. I agree. However the trinary state in my proposal is materially > different - it is the signaling itself that is trinary, not just which > chain is being followed. This allows others to know and make programmatic > decisions (in software) based on that signaling. I'm sure you can agree > that does not exist in BIP8. > > > No additional bit is needed, as softforks are coordinated between users, > NOT miners > > And yet there is miner involvement, as you rightly pointed out. Miners are > needed to set the nVersion in the header. So when you say "no additional > bit is needed", could you please be clearer as to what you mean? Do you > mean that signaling of opposition in a block can be done without any > "additional bit"? Or are you just saying that it is redundant to consider > what miners might be opposing an upgrade? > > @Jorge > > If different users want different incompatible things... there's no way > to avoid the split > > I agree. This happened with bcash, and that's fine. It was painful, but > there were a significant amount of users that disagreed, and they have the > chain they want now. > > But we generally all want to avoid a chain split when possible. Because > chain splits have a cost, and that cost can be high, its likely that many > users would rather choose the chain with the most support rather than > choosing the chain with their preferred rules. > > However, the question here is: how do we estimate what fraction of users > wants which rules? We don't have a divining rod to determine with certainty > what users want. We can only make polls of various levels of inaccuracy. > The methods bitcoin has been using is community discussion and social > consensus estimation as well as miner signaling during the actual > deployment period. Neither of these are perfect, but they are both > reasonable enough mechanisms. However, because both of these mechanisms are > very rough estimates of user sentiment, we need to consider the possibility > that sometimes the estimate may be substantially inaccurate when we design > deployment procedures. This inaccuracy is why we need multiple barriers in > place for an upgrade, and why we need to have higher thresholds of success > (require larger supermajorities in both consensus and miner signaling). > > Developers obviously care about bitcoin and have an incentive (personal > and probably financial) to do it right. And miners have both an incentive > to keep the system healthy, as well as an incentive to mine on the chain > that the economic majority of users is using. But measuring the consensus > of the bitcoin community can be extraordinarily difficult to do with > consistent accuracy, and so I think miner signaling as it has been used as > a second barrier to entry for an upgrade is quite appropriate. > > On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil wrote: > >> I have not objected to anyone splitting. As I said, a split is always >> possible, and of course has been done on a large scale. It is only the >> misleading statements about inherent soft fork “compatibility” and the >> implication that activation without hash power enforcement does not create >> a split that I object to. People who know better should be honest about it. >> >> Far too many people have been led to believe there is so
