damian at willtech.com.au [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-20 📝 Original message:Good Afternoon, There is ...
📅 Original date posted:2021-12-20
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev