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
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
>
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 whe
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
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
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 thoug
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 sli
> 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
> 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
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 e
> 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
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
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 t
13 matches
Mail list logo