>
> By my calculations, at minfee it will cost you ~94 satoshis to spend.
> Dust limit is 294 for Segwit outputs (basically assuming 3x minfee).
>
> So I'm actually happy to say "anchor outputs are 294 satoshi". These
> are simply spendable, and still only $3 each if BTC is $1M. Lower is
>
On Thu, Nov 14, 2019 at 10:56:05AM +0100, Joost Jager wrote:
> Looking at https://github.com/bitcoin/bitcoin/commit/9022aa3, is
> `dustRelayFee` really never going to change? It even is a (hidden) cmd line
> parameter that can be set easily.
>
> If the fee market would rise and stay high for an
Regarding the dust relay limit, there may be a little bit of a
misunderstanding as to a few important details. The purpose of it (much
like the dust output values in the anchor outputs) is to discourage
outputs which are not ever economically spendable, not short-term
uneconomically spendable.
Joost Jager writes:
>>
>> > We could
>> > simplify this to a single to_self_delay that is proposed by the
>> initiator,
>> > but what was the original reason to allow distinct values?
>>
>> Because I didn't fight hard enough for simplicity :(
>>
>
> But the people you were fighting with, what
>
> > We could
> > simplify this to a single to_self_delay that is proposed by the
> initiator,
> > but what was the original reason to allow distinct values?
>
> Because I didn't fight hard enough for simplicity :(
>
But the people you were fighting with, what reason did they have? Just
Joost Jager writes:
>>
>> > * Add `to_remote_delay OP_CHECKSEQUENCEVERIFY OP_DROP` to the `to_remote`
>> > output. `to_remote_delay` is the csv delay that the remote party accepted
>> > in the funding flow for their outputs. This not only ensures that the
>> > carve-out works as intended, but
Matt Corallo writes:
> Why not stick with the original design from Adelaide with a spending path
> with a 1CSV that is anyone can spend (or that is revealed by spending another
> output).
The original design IIRC was a single anyone-can-spend anchor output.
If we need two anchor outputs, and
>
> On Oct 30, 2019, at 06:04, Joost Jager wrote:
>
> > For the anchor outputs we consider:
>> >
>> > * Output type: normal P2WKH. At one point, an additional spending path
>> was
>> > proposed that was unconditional except for a 10 block csv lock. The
>> > intention of this was to prevent utxo
(resend from the right src)
>> On Oct 30, 2019, at 06:04, Joost Jager wrote:
>> > For the anchor outputs we consider:
>> >
>> > * Output type: normal P2WKH. At one point, an additional spending path was
>> > proposed that was unconditional except for a 10 block csv lock. The
>> > intention of
> On Oct 30, 2019, at 03:04, Rusty Russell wrote:
>
> Joost Jager writes:
>> * Add `1 OP_CHECKSEQUENCEVERIFY OP_DROP` to the non-revocation clause of
>> the HTLC outputs.
>
>> For the anchor outputs we consider:
>>
>> * Output type: normal P2WKH. At one point, an additional spending path
Joost Jager writes:
> We started to look at the `push_me` outputs again. Will refer to them as
> `anchor` outputs from now on, to prevent confusion with `push_msat` on the
> `open_channel` message.
>
> The cpfp carve-out https://github.com/bitcoin/bitcoin/pull/15681 has been
> merged and for
>
> * Output type: normal P2WKH. At one point, an additional spending path was
> proposed that was unconditional except for a 10 block csv lock. The
> intention of this was to prevent utxo set pollution by allowing anyone to
> clean up. This however also opens up the possibility for an attacker to
We started to look at the `push_me` outputs again. Will refer to them as
`anchor` outputs from now on, to prevent confusion with `push_msat` on the
`open_channel` message.
The cpfp carve-out https://github.com/bitcoin/bitcoin/pull/15681 has been
merged and for reasons described earlier in this
For the low low cost of 3 witness bytes, I think the simplification of
analysis/separation of concerns is worth it, though I agree it is
probably not strictly required.
On 11/26/18 3:12 AM, Rusty Russell wrote:
Matt Corallo writes:
Hmm, are we willing to consider CLTV sufficient? In case
Matt Corallo writes:
> Hmm, are we willing to consider CLTV sufficient? In case you have two
> HTLCs, one of medium-small value that has a low CLTV and one of high
> value that has a higher CLTV, you could potentially use the soon-CLTV to
> delay the commitment transaction somewhat further if
Indeed, this change assumes (a) the change in relay policy around CPFP
that is discussed on this thread, and (b) some kind of (at least very
basic) package relay in Bitcoin Core. (a) requires some discussion, but
people seem at least not entirely against it when I've discussed it with
people,
On Wed, Nov 21, 2018 at 12:47:17PM +1030, Rusty Russell wrote:
> I'm also starting to implement this, to see what I missed!
>
> - Feerate is fixed at 253 [satoshis per 1,000 weight]
IIUC, this is just over Bitcoin Core's default minimum relay fee of
0.1000 BTC/vByte. That works right now,
Matt Corallo writes:
> Ah, oops, indeed, that is much cleaner :). Still need a CSV of 1, though :(.
OK, let's walk through this:
Locally offered HTLC:
- Local HTLC-Timeout tx is CLTV delayed, but remote can fulfill without delay.
Remote offered HTLC:
- Local HTLC-Success tx can be done without
Not sure if others already realized this, but in thinking about our RBF
policy hack from Adelaide a bit more, to allow the carve-out exception
of "last tx in a package, which has only one unconfirmed ancestor" to
always be available for the "honest party" when broadcasting a
commitment
I'm also starting to implement this, to see what I missed!
Original at https://github.com/lightningnetwork/lightning-rfc/pull/513
Pasted here for your reading convenience:
- Option is sticky; it set at open time, it stays with channel
- I didn't want to have to handle penalty txs on channels
20 matches
Mail list logo
