On Mon, Oct 28, 2019 at 6:16 PM David A. Harding wrote:
> A parent transaction near the limit of 100,000 vbytes could have almost
> 10,000 outputs paying OP_TRUE (10 vbytes per output). If the children
> were limited to 10,000 vbytes each (the current max carve-out size),
> that allows relaying
On Mon, Oct 28, 2019 at 10:45:39AM +0100, Johan Torås Halseth wrote:
> Relay cost is the obvious problem with just naively removing all limits.
> Relaxing the current rules by allowing to add a child to each output as
> long as it has a single unconfirmed parent would still only allow free
> relay
>
>
> I don’te see how? Let’s imagine Party A has two spendable outputs, now
> they stuff the package size on one of their spendable outlets until it is
> right at the limit, add one more on their other output (to meet the
> Carve-Out), and now Party B can’t do anything.
Matt: With the proposed ch
On Thu, Oct 24, 2019 at 03:49:09PM +0200, Johan Torås Halseth wrote:
> [...] what about letting the rule be
>
> The last transaction which is added to a package of dependent
> transactions in the mempool must:
> * Have no more than one unconfirmed parent.
> [... subsequent email ...]
> I realize
Johan,
The issues with mempool limits for OP_SECURETHEBAG are related, but have
distinct solutions.
There are two main categories of mempool issues at stake. One is relay
cost, the other is mempool walking.
In terms of relay cost, if an ancestor can be replaced, it will invalidate
all it's child
I don’te see how? Let’s imagine Party A has two spendable outputs, now they
stuff the package size on one of their spendable outlets until it is right at
the limit, add one more on their other output (to meet the Carve-Out), and now
Party B can’t do anything.
> On Oct 24, 2019, at 21:05, Johan
It essentially changes the rule to always allow CPFP-ing the commitment as
long as there is an output available without any descendants. It changes
the commitment from "you always need at least, and exactly, one non-CSV
output per party. " to "you always need at least one non-CSV output per
party.
I may be missing something, but I'm not sure how this changes anything?
If you have a commitment transaction, you always need at least, and
exactly, one non-CSV output per party. The fact that there is a size
limitation on the transaction that spends for carve-out purposes only
effects how many ot
Reviving this old thread now that the recently released RC for bitcoind
0.19 includes the above mentioned carve-out rule.
In an attempt to pave the way for more robust CPFP of on-chain contracts
(Lightning commitment transactions), the carve-out rule was added in
https://github.com/bitcoin/bitcoin
Matt Corallo writes:
>>> Thus, even if you imagine a steady-state mempool growth, unless the
>>> "near the top of the mempool" criteria is "near the top of the next
>>> block" (which is obviously *not* incentive-compatible)
>>
>> I was defining "top of mempool" as "in the first 4 MSipa", ie. ne
I responded to a few things in-line before realizing I think we're out of sync
on what this alternative proposal actually implies. In my understanding is it,
it does *not* imply that you are guaranteed the ability to RBF as fees change.
The previous problem is still there - your counterparty can
Matt Corallo writes:
> Ultimately, defining a "near the top of the mempool" criteria is fraught
> with issues. While it's probably OK for the original problem (large
> batched transactions where you don't want a single counterparty to
> prevent confirmation), lightning's requirements are very d
Sorry for the late reply.
Hmm, I included the old RBF-pinning proposal as a comparison.
Personally, I find it both less clean and less convincingly secure.
Ultimately, defining a "near the top of the mempool" criteria is fraught
with issues. While it's probably OK for the original problem (la
Matt Corallo writes:
> As an alternative proposal, at various points there have been
> discussions around solving the "RBF-pinning" problem by allowing
> transactors to mark their transactions as "likely-to-be-RBF'ed", which
> could enable a relay policy where children of such transactions woul
(cross-posted to both lists to make lightning-dev folks aware, please
take lightning-dev off CC when responding).
As I'm sure everyone is aware, Lightning (and other similar systems)
work by exchanging pre-signed transactions for future broadcast. Of
course in many cases this requires either (
15 matches
Mail list logo
