Hi Greg,
> The security of LN and other related systems are something like: "given
> proper fees offered, can a transaction be mined within N blocks?" You're
> simply not allowed to out-bid your attacker in certain circumstances due to
> today's miner incentive-incompatible relay policies.
It
> If something relies on a policy which can be changed without breaking
consensus rules, how is it secure in any case with or without full rbf?
The security of LN and other related systems are something like: "given
proper fees offered, can a transaction be mined within N blocks?" You're
simply no
Hi Antoine,
Thanks for opening the pull request to add support for full-rbf in Bitcoin
Core. I have a few disagreements with the approach and questions.
> Recent discussions among LN devs have brought back on the surface concerns
> about the security of multi-party funded transactions (coinjoin
> two aspects to consensus
Well, consensus isn't just one thing with two aspects. There are many
things one might ask for consensus about, and many groups you might ask for
it from. There's miner consensus about transaction ordering, miner
consensus about soft fork signaling, developer consensus
> I do reiterate that it is blindingly easy to pin a public hash to the
> bitcoin blockchain that asserts the earliest publication of a document
> or collection of documents, and that this is desperately needed, to
> protect the accuracy of history when it is not safe.
The concern raised here rela
On 6/14/22, Andrew Poelstra wrote:
> On Tue, Jun 14, 2022 at 01:15:08PM -0400, Undiscussed Horrific Abuse, One
> Victim of Many via bitcoin-dev wrote:
>> I'm replying to Peter, skipping the other emails.
>>
>> I perceive all these emails as disruptive trolling, ignoring the
>> importance of real t