Re: [bitcoin-dev] Making OP_TRUE standard?

Rusty Russell writes: > AFAICT the optimal DoS is where: > > 1. Attacker sends a 100,000 vbyte tx @1sat/vbyte. > 2. Replaces it with a 108 vbyte tx @2sat/vbyte which spends one of > those inputs. > 3. Replaces that spent input in the 100k tx and does it again. > > It takes 3.5 seconds to

Re: [bitcoin-dev] Making OP_TRUE standard?

Peter Todd writes: > On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote: >> Jim Posen writes: >> > I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF >> > on the spending tx? >> >> Marco points out that if the parent is RBF, this child

Re: [bitcoin-dev] Making OP_TRUE standard?

In the thread "Revisting BIP 125 RBF policy" @ https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015797.html I propose replacing rule 3 with a rule that instead demands that the replacement

Re: [bitcoin-dev] Making OP_TRUE standard?

On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote: > Jim Posen writes: > > I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF > > on the spending tx? > > Marco points out that if the parent is RBF, this child inherits it,

Re: [bitcoin-dev] Making OP_TRUE standard?

Jim Posen writes: > I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF > on the spending tx? Marco points out that if the parent is RBF, this child inherits it, so we're actually good here. However, Matt Corallo points out that you can block RBF

Re: [bitcoin-dev] Making OP_TRUE standard?

> > This brings us another theoretical problem: someone could spend our > OP_TRUE with a low-fee non-RBF tx, and we'd not be able to use it to > CPFP the tx. It'd be hard to do, but possible. I think the network > benefits from using OP_TRUE (anyone can clean, and size, vs some >

Re: [bitcoin-dev] Making OP_TRUE standard?

ZmnSCPxj via bitcoin-dev writes: > Good morning Rusty and list, > >> Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is >> interesting, >> >> but if we want a SF just give us SIGHASH_NOINPUT and we'll not need >> this >> >> at all (though others

Re: [bitcoin-dev] Making OP_TRUE standard?

Good morning Rusty and list, > Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is interesting, > > but if we want a SF just give us SIGHASH_NOINPUT and we'll not need this > > at all (though others still might). We might still want this in general in Lightning; for instance we could

Re: [bitcoin-dev] Making OP_TRUE standard?

Good morning Luke, > (Maybe it should be the first output > > instead of the last... Is there any legitimate reason one would have multiple > > such dummy outputs?) None, but how about use of `SIGHASH_SINGLE` flag? If a dummy output is added as the first, would it not require adjustment of

Re: [bitcoin-dev] Making OP_TRUE standard?

Good morning Luke and list, > > (Aside, in case it wasn't clear on my previous email, the template-script idea > > would not make it mandatory to spend in the same block, but that the UTXO > > would merely cease to be valid after that block. So the 0-value output does > > not take up a UTXO

Re: [bitcoin-dev] Making OP_TRUE standard?

You'd send 0 satoshis to OP_TRUE, creating a UTXO. Then you spend that 0-value UTXO in another transaction with a normal fee. The idea is that to get the latter fee, the miner needs to confirm the original tranaction with the 0-value OP_TRUE. (Aside, in case it wasn't clear on my previous

Re: [bitcoin-dev] Making OP_TRUE standard?

But in prnciple I don't oppose to making it stardard, just want to understand what's the point. On Thu, 10 May 2018, 02:16 Jorge Timón, wrote: > I fail to see what's the practical difference between sending to op_true > and giving the coins are fees directly. Perhaps it is ao

Re: [bitcoin-dev] Making OP_TRUE standard?

I fail to see what's the practical difference between sending to op_true and giving the coins are fees directly. Perhaps it is ao obvious to you that you forget to mention it? If you did I honestlt missed it. On Wed, 9 May 2018, 01:58 Rusty Russell via 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

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

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

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

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

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”

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

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

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

Re: [bitcoin-dev] Making OP_TRUE standard?

Good morning Olauluwa, I believe P2WSH is larger due to the script hash commitment in the `scriptPubKey` as well as the actual script revelation in the `witnessScript`, whereas, a flat OP_TRUE in the `scriptPubKey` is much smaller and can be spent with an empty `scriptSig`. It seems this is

Re: [bitcoin-dev] Making OP_TRUE standard?

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. On Tue, May 8, 2018, 4:58 PM Rusty Russell via bitcoin-dev <

[bitcoin-dev] Making OP_TRUE standard?

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