From: damian@willtech•com.au
To: Peter Todd <pete@petertodd•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
Date: Sun, 19 Dec 2021 18:30:57 -0800 [thread overview]
Message-ID: <a156e0fb6fc2a62813a4ff1aecfe5ae7@willtech.com.au> (raw)
In-Reply-To: <Yb4fx0ny0tZYKmrD@petertodd.org>
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
next prev parent reply other threads:[~2021-12-20 2:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-15 16:55 Antoine Riard
2021-06-17 0:58 ` Billy Tetrud
2021-06-17 22:28 ` Greg Sanders
2021-06-25 0:23 ` Antoine Riard
2021-06-26 16:13 ` Billy Tetrud
2021-06-26 19:00 ` Jeremy
2021-06-30 14:06 ` Corey Haddad
2021-06-30 19:21 ` Billy Tetrud
2021-12-18 16:51 ` Jeremy
2021-12-18 17:52 ` Peter Todd
2021-12-20 2:30 ` damian [this message]
2021-12-19 18:55 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a156e0fb6fc2a62813a4ff1aecfe5ae7@willtech.com.au \
--to=damian@willtech$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox