Interesting work! I should be fortunate to make time to read it.
I will point out, in case you'd not considered it, that you can support
addition and removal indirectly by formulating it as a difference of sets.
Similar to the collision-resistant replicated data types (CRDTs) concept.
Checking
Le 08/06/2020 à 06:56, ZmnSCPxj via bitcoin-dev a écrit :
> Running both Bitcoin and Lightning nodes on clearnet automatically links
> them, making them easier to attack, whereas running Lightning on Tor does not.
> Of course, they could still be linked by onchain transaction monitoring, but
>
Dear all,
I have been working on some constructions for cryptographic accumulators
that optimise for quick insertion.
As a brief background, an accumulator is a data structure that maintains
compact commitments to a potentially very large (and dynamic) set, while
keeping proofs of membership
В Sun, 7 Jun 2020 23:43:39 -0700
Jeremy via bitcoin-dev wrote:
> > PFN transaction would still be valid if some of 'ghost parents' are
> >
> already confirmed, so the miners could have more fees than strictly
> necessary. But this is the same as with CPFP.
>
> This is problematic and can't be
В Sun, 7 Jun 2020 15:45:16 -0700
Jeremy via bitcoin-dev wrote:
> What I think we'll eventually land on is a way of doing a tx
> that contributes fee to another tx chain as a passive observer to
> them. While this breaks one abstraction around how dependencies
> between transactions are
Broke out to a separate thread.
At core, the reason why this method *might* work is that it's essentially
just CPFP but we can guarantee that the link we're examining is always
exactly one hop away, so we get rid of most of the CPFP graph traversal
issues.
Your description largely matches my
