[bitcoin-dev] [Bitcoin Advent Calendar] NFTs Part Two: Auctions, Royalties, Mints, Generative, Game Items

[Jeremy via bitcoin-dev]

Hi Devs!

More on NFTs today! Code demos of dutch auctions of NFTs + royalties, and
then discussion of a few other concepts I'm excited about.

https://rubin.io/bitcoin/2021/12/19/advent-22/

Particularly novel is the combination of attestation chains, lightning
invoices, and NFTs to create off-chain updatable and on-chain sellable
in-game items.

Till tomorrow!

Cheers,

Jeremy

--
@JeremyRubin 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

[Antoine Riard via bitcoin-dev]

> we might start with 60 seconds, and then double every release till we get
to 600 at which point we disable it.

This is clearly new. However, I'm not sure if it's solving multi-party
funding transaction DoS, which was of the motivation to propose to
deprecate opt-in RBF. The malicious counterparty can broadcast its
low-feerate, opt-out spending of its own collateral input far before to
engage in the cooperative funding.

When the funding transaction starts to propagate, the opt-out has been
"first seen" for a while, the replaceability is turned off, the honest
funding is bounced off ?


Taking opportunity to laid out another proposal which has whispered to me
offline :

"(what) if the nversion of outputs (which is set by their creating
transaction) were inspected and
triggered any spend of the output to be required to be flagged to be
replaceable-- as a standardness rule?"

While working to solve the DoS, I believe this approach is introducing an
overhead cost in the funding of multi-party transactions, as from now on,
you have to sanitize your collateral inputs by sending them first to a
replaceable nVersion outputs ? (iirc, this is done by Lightning Pool, where
you have a first step where the inputs are locked in a 2-of-2 with the
orchester before to engage in the batch execution tx).

Current state of the discussion is to introduce a `fullrbf` config-knob
turned to false, see more context here :
https://gnusha.org/bitcoin-core-dev/2021-10-21.log. Proposing an
implementation soon.

Antoine

Le sam. 18 déc. 2021 à 11:51, Jeremy  a écrit :

> Small idea:
>
> ease into getting rid of full-rbf by keeping the flag working, but make
> enforcement of non-replaceability something that happens n seconds after
> first seen.
>
> this reduces the ability to partition the mempools by broadcasting
> irreplaceable conflicts all at once, and slowly eases clients off of
> relying on non-RBF.
>
> we might start with 60 seconds, and then double every release till we get
> to 600 at which point we disable it.
> --
> @JeremyRubin 
> 
>
>
> On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi,
>>
>> I'm writing to propose deprecation of opt-in RBF in favor of full-RBF as
>> the Bitcoin Core's default replacement policy in version 24.0. As a
>> reminder, the next release is 22.0, aimed for August 1st, assuming
>> agreement is reached, this policy change would enter into deployment phase
>> a year from now.
>>
>> Even if this replacement policy has been deemed as highly controversial a
>> few years ago, ongoing and anticipated changes in the Bitcoin ecosystem are
>> motivating this proposal.
>>
>> # RBF opt-out as a DoS Vector against Multi-Party Funded Transactions
>>
>> As explained in "On Mempool Funny Games against Multi-Party Funded
>> Transactions'', 2nd issue [0], an attacker can easily DoS a multi-party
>> funded transactions by propagating an RBF opt-out double-spend of its
>> contributed input before the honest transaction is broadcasted by the
>> protocol orchester. DoSes are qualified in the sense of either an attacker
>> wasting timevalue of victim's inputs or forcing exhaustion of the
>> fee-bumping  reserve.
>>
>> This affects a series of Bitcoin protocols such as Coinjoin, onchain DLCs
>> and dual-funded LN channels. As those protocols are still in the early
>> phase of deployment, it doesn't seem to have been executed in the wild for
>> now.  That said, considering that dual-funded are more efficient from a
>> liquidity standpoint, we can expect them to be widely relied on, once
>> Lightning enters in a more mature phase. At that point, it should become
>> economically rational for liquidity service providers to launch those DoS
>> attacks against their competitors to hijack user traffic.
>>
>> Beyond that, presence of those DoSes will complicate the design and
>> deployment of multi-party Bitcoin protocols such as payment
>> pools/multi-party channels. Note, Lightning Pool isn't affected as there is
>> a preliminary stage where batch participants are locked-in their funds
>> within an account witnessScript shared with the orchestrer.
>>
>> Of course, even assuming full-rbf, propagation of the multi-party funded
>> transactions can still be interfered with by an attacker, simply
>> broadcasting a double-spend with a feerate equivalent to the honest
>> transaction. However, it tightens the attack scenario to a scorched earth
>> approach, where the attacker has to commit equivalent fee-bumping reserve
>> to maintain the pinning and might lose the "competing" fees to miners.
>>
>> # RBF opt-out as a Mempools Partitions Vector
>>
>> A longer-term issue is the risk of mempools malicious partitions, where
>> an attacker exploits network topology or divergence in mempools policies to
>> partition network mempools in different subsets. From then a wide range of
>> attacks can be