Good morning Jeremy,
> > ## Why would a "Smart" contract be "Smart"?
> >
> > A "smart" contract is simply one that somehow self-enforces rather than
> > requires a third party to enforce it.
> > It is "smart" because its execution is done automatically.
>
> There are no automatic executing smart
Hi Jeremy,
Thanks for sharing your thoughts.
To summarize your arguments: the intentionally malicious path to getting
the 0 sat output confirmed without being spent is uneconomical compared to
simply creating dust outputs. And even if it does happen, the tx spending
from the 0 sat output may stil
Devs,
For today's post, something near and dear to our hearts: giving our sats to
our loved ones after we kick the bucket.
see: https://rubin.io/bitcoin/2021/12/08/advent-11/
Some interesting primitives, hopefully enough to spark a discussion around
different inheritance schemes that might be us
IMO this is not a big problem. The problem is not if a 0 value ever enters
the mempool, it's if it is never spent. And even if C2/P1 goes in, C1 still
can be spent. In fact, it increases it's feerate with P1's confirmation so
it's somewhat likely it would go in. C2 further has to be pretty expensiv
Bastien,
The issue is that with Decker Channels you either use SIGHASH_ALL / APO and
don't allow adding outs (this protects against certain RBF pinning on the
root with bloated wtxid data) and have anchor outputs or you do allow them
and then are RBF pinnable (but can have change).
Assuming you u
Hi Gloria,
I agree with regard to the RBF changes. To me, we should (obviously?) do
ancestor feerate instead of requiring confirmed inputs (#23121).
However, we are yet to come with a reasonable policy-only fix to "rule 3
pinning".
Responses inline!
>> The part of Revault we are interested in
Hi Jeremy,
I brought up the exact same thing at coredev, but unfortunately I came up
with a way in which the 0 sat output could still enter the UTXO set under
those rules:
- Parent P1 (0 sat per byte) has 2 outputs, one is 0 sat
- Child C1 spends the 0 sat output for a combined feerate of 1 sat p
Hi Jeremy,
Right now, lightning anchor outputs use a 330 sats amount. Each commitment
transaction has two such outputs, and only one of them is spent to help the
transaction get confirmed, so the other stays there and bloats the utxo set.
We allow anyone to spend them after a csv of 16 blocks, in
