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?

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?

> 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

[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

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

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?

> 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] 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

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?

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?

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?

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