Re: [bitcoin-dev] Making OP_TRUE standard?
You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set Instead, would you consider to use ANYONECANPAY to sign the tx, so it is possible add more inputs for fees? The total tx size is bigger than the OP_TRUE approach, but you don’t need to ask for any protocol change. In long-term, I think the right way is to have a more flexible SIGHASH system to allow people to add more inputs and outputs easily. > On 9 May 2018, at 7:57 AM, Rusty Russell via bitcoin-dev > wrote: > > Hi all, > >The largest problem we are having today with the lightning > protocol is trying to predict future fees. Eltoo solves this elegantly, > but meanwhile we would like to include a 546 satoshi OP_TRUE output in > commitment transactions so that we use minimal fees and then use CPFP > (which can't be done at the moment due to CSV delays on outputs). > > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is > non-standard. Are there any reasons not to suggest such a policy > change? > > Thanks! > Rusty. > ___ > 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] Making OP_TRUE standard?
On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote: > You should make a “0 fee tx with exactly one OP_TRUE output” standard, but > nothing else. This makes sure CPFP will always be needed, so the OP_TRUE > output won’t pollute the UTXO set > > Instead, would you consider to use ANYONECANPAY to sign the tx, so it is > possible add more inputs for fees? The total tx size is bigger than the > OP_TRUE approach, but you don’t need to ask for any protocol change. > > In long-term, I think the right way is to have a more flexible SIGHASH system > to allow people to add more inputs and outputs easily. I don't think that will work, as a zero-fee tx won't get relayed even with CPFP, due to the fact that we haven't yet implemented package-based tx relaying. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making OP_TRUE standard?
> On 10 May 2018, at 3:27 AM, Peter Todd wrote: > > On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote: >> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but >> nothing else. This makes sure CPFP will always be needed, so the OP_TRUE >> output won’t pollute the UTXO set >> >> Instead, would you consider to use ANYONECANPAY to sign the tx, so it is >> possible add more inputs for fees? The total tx size is bigger than the >> OP_TRUE approach, but you don’t need to ask for any protocol change. >> >> In long-term, I think the right way is to have a more flexible SIGHASH >> system to allow people to add more inputs and outputs easily. > > I don't think that will work, as a zero-fee tx won't get relayed even with > CPFP, due to the fact that we haven't yet implemented package-based tx > relaying. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org My only concern is UTXO pollution. There could be a “CPFP anchor” softfork that outputs with empty scriptPubKey and 0 value are spendable only in the same block. If not spent immediately, they become invalid and are removed from UTXO. But I still think the best solution is a more flexible SIGHASH system, which doesn’t need CPFP at all. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making OP_TRUE standard?
On Thu, May 10, 2018 at 04:19:31AM +0800, Johnson Lau wrote: > > > > On 10 May 2018, at 3:27 AM, Peter Todd wrote: > > > > On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote: > >> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but > >> nothing else. This makes sure CPFP will always be needed, so the OP_TRUE > >> output won’t pollute the UTXO set > >> > >> Instead, would you consider to use ANYONECANPAY to sign the tx, so it is > >> possible add more inputs for fees? The total tx size is bigger than the > >> OP_TRUE approach, but you don’t need to ask for any protocol change. > >> > >> In long-term, I think the right way is to have a more flexible SIGHASH > >> system to allow people to add more inputs and outputs easily. > > > > I don't think that will work, as a zero-fee tx won't get relayed even with > > CPFP, due to the fact that we haven't yet implemented package-based tx > > relaying. > > > > -- > > https://petertodd.org 'peter'[:-1]@petertodd.org > > My only concern is UTXO pollution. There could be a “CPFP anchor” softfork > that outputs with empty scriptPubKey and 0 value are spendable only in the > same block. If not spent immediately, they become invalid and are removed > from UTXO. But I still think the best solution is a more flexible SIGHASH > system, which doesn’t need CPFP at all. I don't see any reason why UTXO pollution would be a special concern so long as those outputs are subject to the same dust rules as any other output is. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making OP_TRUE standard?
> Instead, would you consider to use ANYONECANPAY to sign the tx, so it is > possible add more inputs for fees? The total tx size is bigger than the > OP_TRUE approach, but you don’t need to ask for any protocol change. If one has a "root" commitment with other nested descendent multi-transaction contracts, then changing the txid of the root commitment will invalidated all the nested multi tx contracts. In our specific case, we have pre-signed 2-stage HTLC transaction which rely on a stable txid. As a result, we can't use the ANYONECANPAY approach atm. > In long-term, I think the right way is to have a more flexible SIGHASH > system to allow people to add more inputs and outputs easily. Agreed, see the recent proposal to introduce SIGHASH_NOINPUT as a new sighash type. IMO it presents an opportunity to introduce more flexible fine grained sighash inclusion control. -- Laolu On Wed, May 9, 2018 at 11:12 AM Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > You should make a “0 fee tx with exactly one OP_TRUE output” standard, but > nothing else. This makes sure CPFP will always be needed, so the OP_TRUE > output won’t pollute the UTXO set > > Instead, would you consider to use ANYONECANPAY to sign the tx, so it is > possible add more inputs for fees? The total tx size is bigger than the > OP_TRUE approach, but you don’t need to ask for any protocol change. > > In long-term, I think the right way is to have a more flexible SIGHASH > system to allow people to add more inputs and outputs easily. > > > > > On 9 May 2018, at 7:57 AM, Rusty Russell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > Hi all, > > > >The largest problem we are having today with the lightning > > protocol is trying to predict future fees. Eltoo solves this elegantly, > > but meanwhile we would like to include a 546 satoshi OP_TRUE output in > > commitment transactions so that we use minimal fees and then use CPFP > > (which can't be done at the moment due to CSV delays on outputs). > > > > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is > > non-standard. Are there any reasons not to suggest such a policy > > change? > > > > Thanks! > > Rusty. > > ___ > > 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] BIP sighash_noinput
> The current proposal kind-of limits the potential damage by still committing > to the prevout amount, but it still seems a big risk for all the people that > reuse addresses, which seems to be just about everyone. The typical address re-use doesn't apply here as this is a sighash flag that would only really be used for doing various contracts on Bitcoin. I don't see any reason why "regular" wallets would update to use this sighash flag. We've also seen first hand with segwit that wallet authors are slow to pull in the latest and greatest features available, even if they solve nuisance issues like malleability and can result in lower fees. IMO, sighash_none is an even bigger footgun that already exists in the protocol today. -- Laolu On Tue, May 8, 2018 at 7:41 AM Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev > wrote: > > Given the general enthusiasm, and lack of major criticism, for the > > `SIGHASH_NOINPUT` proposal, [...] > > So first, I'm not sure if I'm actually criticising or playing devil's > advocate here, but either way I think criticism always helps produce > the best proposal, so > > The big concern I have with _NOINPUT is that it has a huge failure > case: if you use the same key for multiple inputs and sign one of them > with _NOINPUT, you've spent all of them. The current proposal kind-of > limits the potential damage by still committing to the prevout amount, > but it still seems a big risk for all the people that reuse addresses, > which seems to be just about everyone. > > I wonder if it wouldn't be ... I'm not sure better is the right word, > but perhaps "more realistic" to have _NOINPUT be a flag to a signature > for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead, > so that it's fundamentally not possible to trick someone who regularly > reuses keys to sign something for one input that accidently authorises > spends of other inputs as well. > > Is there any reason why an OP_CHECKSIG_1USE (or OP_CHECKMULTISIG_1USE) > wouldn't be equally effective for the forseeable usecases? That would > ensure that a _NOINPUT signature is only ever valid for keys deliberately > intended to be single use, rather than potentially valid for every key. > > It would be ~34 witness bytes worse than being able to spend a Schnorr > aggregate key directly, I guess; but that's not worse than the normal > taproot tradeoff: you spend the aggregate key directly in the normal, > cooperative case; and reserve the more expensive/NOINPUT case for the > unusual, uncooperative cases. I believe that works fine for eltoo: in > the cooperative case you just do a SIGHASH_ALL spend of the original > transaction, and _NOINPUT isn't needed. > > Maybe a different opcode maybe makes sense at a "philosophical" level: > normal signatures are signing a spend of a particular "coin" (in the > UTXO sense), while _NOINPUT signatures are in some sense signing a spend > of an entire "wallet" (all the coins spendable by a particular key, or > more accurately for the current proposal, all the coins of a particular > value spendable by a particular key). Those are different intentions, > so maybe it's reasonable to encode them in different addresses, which > in turn could be done by having a new opcode for _NOINPUT. > > A new opcode has the theoretical advantage that it could be deployed > into the existing segwit v0 address space, rather than waiting for segwit > v1. Not sure that's really meaningful, though. > > Cheers, > aj > > ___ > 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] Why not archive the backend of Bitcoin blockchain?
On 3/17/18, someone posted on the Lightning-dev list, "Can I try Lightning without running a fully-fledged bitcoin block chain? (Yubin Ruan)." The inquirer was asking because he didn't have much space to store the entire blockchain on his laptop. I replied: "Developers, On THIS note and slightly off-topic but relevant, why can't chunks of blockchain peel off the backend periodically and be archived, say on minimum of 150 computers across 7 continents? It seems crazy to continue adding on to an increasingly long chain to infinity if the old chapters (i.e. more than, say, 2 years old) could be stored in an evenly distributed manner across the planet. The same 150 computers would not need to store every chapter either, just the index would need to be widely distributed in order to reconnect with a chapter if needed. Then maybe it is no longer a limitation in the future for people like Yubin. " It was suggested by a couple of lightning developers that I post this idea on the bitcoin-dev list. So, here I post :). Segue ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making OP_TRUE standard?
Olaoluwa Osuntokun writes: > What are the downsides of just using p2wsh? This route can be rolled out > immediately, while policy changes are pretty "fuzzy" and would require a > near uniform rollout in order to ensure wide propagation of the commitment > transactions. I expect we will, but thougth I'd ask :) I get annoyed when people say "We found this issue, but we worked around it and so never bothered you with it!" for my projects :) Cheers, Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP sighash_noinput
Anthony Towns via bitcoin-dev writes: > On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev > wrote: >> Given the general enthusiasm, and lack of major criticism, for the >> `SIGHASH_NOINPUT` proposal, [...] > > So first, I'm not sure if I'm actually criticising or playing devil's > advocate here, but either way I think criticism always helps produce > the best proposal, so > > The big concern I have with _NOINPUT is that it has a huge failure > case: if you use the same key for multiple inputs and sign one of them > with _NOINPUT, you've spent all of them. The current proposal kind-of > limits the potential damage by still committing to the prevout amount, > but it still seems a big risk for all the people that reuse addresses, > which seems to be just about everyone. If I can convince you to sign with SIGHASH_NONE, it's already a problem today. > I wonder if it wouldn't be ... I'm not sure better is the right word, > but perhaps "more realistic" to have _NOINPUT be a flag to a signature > for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead, > so that it's fundamentally not possible to trick someone who regularly > reuses keys to sign something for one input that accidently authorises > spends of other inputs as well. That was also suggested by Mark Friedenbach, but I think we'll end up with more "magic key" a-la Schnorr/taproot/graftroot and less script in future. That means we'd actually want a different Segwit version for "NOINPUT-can-be-used", which seems super ugly. > Maybe a different opcode maybe makes sense at a "philosophical" level: > normal signatures are signing a spend of a particular "coin" (in the > UTXO sense), while _NOINPUT signatures are in some sense signing a spend > of an entire "wallet" (all the coins spendable by a particular key, or > more accurately for the current proposal, all the coins of a particular > value spendable by a particular key). Those are different intentions, > so maybe it's reasonable to encode them in different addresses, which > in turn could be done by having a new opcode for _NOINPUT. In a world where SIGHASH_NONE didn't exist, this might be an argument :) Cheers, Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making OP_TRUE standard?
Johnson Lau writes: > You should make a “0 fee tx with exactly one OP_TRUE output” standard, but > nothing else. This makes sure CPFP will always be needed, so the OP_TRUE > output won’t pollute the UTXO set That won't propagate :( > Instead, would you consider to use ANYONECANPAY to sign the tx, so it > is possible add more inputs for fees? The total tx size is bigger than > the OP_TRUE approach, but you don’t need to ask for any protocol > change. No, that would change the TXID, which we rely on for HTLC transactions. > In long-term, I think the right way is to have a more flexible SIGHASH system > to allow people to add more inputs and outputs easily. Agreed: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015862.html But in the long term we'll have Eltoo and SIGHASH_NOINPUT which both allow different solutions. Cheers, Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making OP_TRUE standard?
An OP_TRUE-only script with a low value seems like a good example of where the weight doesn't reflect the true cost: it uses a UTXO forever, while only costing a weight of 4. I like Johnson's idea to have some template (perhaps OP_2-only, to preserve expected behaviour of OP_TRUE-only) that when combined with a 0-value is always valid only if spent in the same block. I wonder if it would make sense to actually tie it to a transaction version bit, such that when the bit is set, the transaction is serialised with +1 on the output count and 0181 is simply injected into the transaction hashing... But for now, simply having a consensus rule that a bit MUST be set for the expected behaviour, and the bit may ONLY be set when the last output is exactly 0181, would allow us to code the transaction serialisation up later. (Maybe it should be the first output instead of the last... Is there any legitimate reason one would have multiple such dummy outputs?) Luke On Tuesday 08 May 2018 23:57:11 Rusty Russell via bitcoin-dev wrote: > Hi all, > > The largest problem we are having today with the lightning > protocol is trying to predict future fees. Eltoo solves this elegantly, > but meanwhile we would like to include a 546 satoshi OP_TRUE output in > commitment transactions so that we use minimal fees and then use CPFP > (which can't be done at the moment due to CSV delays on outputs). > > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is > non-standard. Are there any reasons not to suggest such a policy > change? > > Thanks! > Rusty. > ___ > 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] Making OP_TRUE standard?
Good morning Luke and list, > An OP_TRUE-only script with a low value seems like a good example of where the > > weight doesn't reflect the true cost: it uses a UTXO forever, while only > > costing a weight of 4. > > I like Johnson's idea to have some template (perhaps OP_2-only, to preserve > > expected behaviour of OP_TRUE-only) that when combined with a 0-value is > > always valid only if spent in the same block. I understand the issue. On Lightning side, if this rule is used, we would have the two options below: 1. Commitment transactions always use the minimum feerate, but always have the above OP_TRUE output. Then to confirm the commitment transaction we would have to always spend the OP_TRUE output in CPFP transaction that pays for actual fee at unilateral close. This consumes more blockchain space for unilateral closes, as the second transaction is always mandatory. 2. We store two commitment transactions and associated paraphernalia (further transactions to claim the HTLCs). One version has a negotiated feerate without the OP_TRUE output. The other version has a slightly increased feerate and an OP_TRUE output as above. At unilateral close, we see if the negotiated feerate is enough and use that version if possible, but if not we RBF it with other version and in addition also CPFP on top. As mentioned before, we do not have transaction packages, so we need to RBF with higher feerate the commitment transaction, then submit the CPFP transaction which makes the first transaction valid to include in a block as per the rule. This requires that the fallback always have both an RBF bump and a CPFP bump. > >(Maybe it should be the first output > > instead of the last... Is there any legitimate reason one would have multiple > > such dummy outputs?) It seems there are indeed none. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?
He can use pruning to only store the last X MB of the blockchain. It will store the UTXO set though, which is a couple of GBs. In total, a pruned node with pruning set to 1000 MB ends up using 4.5 GB currently, but it varies slightly due to the # of UTXOs in existence. On Thu, May 10, 2018 at 9:56 AM, Segue via bitcoin-dev wrote: > On 3/17/18, someone posted on the Lightning-dev list, "Can I try Lightning > without running a fully-fledged bitcoin block chain? (Yubin Ruan)." The > inquirer was asking because he didn't have much space to store the entire > blockchain on his laptop. > > I replied: > > "Developers, > > On THIS note and slightly off-topic but relevant, why can't chunks of > blockchain peel off the backend periodically and be archived, say on minimum > of 150 computers across 7 continents? > > It seems crazy to continue adding on to an increasingly long chain to > infinity if the old chapters (i.e. more than, say, 2 years old) could be > stored in an evenly distributed manner across the planet. The same 150 > computers would not need to store every chapter either, just the index would > need to be widely distributed in order to reconnect with a chapter if > needed. Then maybe it is no longer a limitation in the future for people > like Yubin. " > > It was suggested by a couple of lightning developers that I post this idea > on the bitcoin-dev list. So, here I post :). > > Segue > > > > > ___ > 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