MIME-Version: 1.0
Date: Sun, 19 Dec 2021 18:30:57 -0800
From: damian@willtech.com.au
To: Peter Todd <pete@petertodd.org>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <Yb4fx0ny0tZYKmrD@petertodd.org>
References: <CALZpt+F2b3tdu1+kLZiBPCH2O-pDzZytoRFtX6X0a8UX4OBrDQ@mail.gmail.com>
 <CAD5xwhjVkxgu2+M+Ft576GYM6Tv=ZEwtV82v1cLeYaoU5mSRnA@mail.gmail.com>
 <Yb4fx0ny0tZYKmrD@petertodd.org>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <a156e0fb6fc2a62813a4ff1aecfe5ae7@willtech.com.au>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
Precedence: list

Good Afternoon,

There is no such thing in Bitcoin as zeroconf but any individual may use 
gossip from mempool if they choose it to prefer it could be possible a 
transaction could exist in the future. You are talking about the 
mempool. The mempool exists on gossip. There are no transactions until 
they are mined and included in a block and information can disappear 
from the mempool. This is Bitcoin where we scientifically make a 
consensus to assure fungibility.

KING JAMES HRMH
Great British Empire

Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills

et al.


Willtech
www.willtech.com.au
www.go-overt.com
duigco.org DUIGCO API
and other projects


m. 0487135719
f. +61261470192


This email does not constitute a general advice. Please disregard this 
email if misdelivered.
On 2021-12-18 09:52, Peter Todd via bitcoin-dev wrote:
> On Sat, Dec 18, 2021 at 08:51:46AM -0800, Jeremy via bitcoin-dev wrote:
>> 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.
> 
> Making replacability turn on _after_ an expiry time is reached has been
> suggested before, IIRC by Matt Corallo. However I believe the approach 
> of
> enabling full-rbf _until_ a time is reached is clever and novel.
> 
> I'd suggest doing both at once. Long-running txs are certainly useful. 
> But if a
> tx hasn't been mined in a few blocks, it certainly can't be relied on 
> for
> zeroconf.
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev