Hi Peter,
Thanks you for investigate my concern and replicate the scenario I drafted.
On 27.01.24 02:19, Peter Todd wrote:
I actually tried this attack out, and it fails at step #4 due to the Rule #6,
PaysMoreThanConflicts, check.
While on stacker.news you stated that:
tx_HS has 5000 vB
Hi Peter,
On 1/22/24 17:52, Peter Todd wrote:
An even simpler fix would be to just require that all unconfirmed inputs
in a replacement come from the *same* replaced transaction. That would
make certain rare, but economically viable, replacements infeasible. But
it would definitely fix the iss
Hi Peter,
On 1/18/24 13:23, Peter Todd via bitcoin-dev wrote:
> Reposting this blog post here for discussion:
>
> https://petertodd.org/2024/one-shot-replace-by-fee-rate
I saw your proposal mentioned on Stacker News and read it with interest.
In response, I described a replacement cycle that ca
Hi John,
On 2023-08-06 16:35, John Light via bitcoin-dev wrote:
is there ever a case where using OP_RETURN
to embed data actually results in fewer bytes onchain than
embedding the same data using the segwit/taproot witness space
Yes, a back-of-the-envelo
Hey everyone,
Over the years, I have participated in a few conversations about various
aspects of transactions. Often a chunk of the conversation is spent on
establishing a shared vocabulary. There are many competing terms—e.g. I
can think of at least three additional terms that refer to `scri
Hi Pieter, hello list,
On 26.10.22 12:39, Pieter Wuille via bitcoin-dev wrote:
1. The most straightforward solution is using the BIP process as-is: let BIP324
introduce a fixed initial table, and future BIPs which introduce new
messages can introduce new mapping entries for it. In theory
Hello John,
On 17.10.22 02:23, John Carvalho via bitcoin-dev wrote:
Simply, 0conf acceptance can be monitored and enforced by the merchant and
exposure to doublespends can be both mitigated and limited in size per block.
It is less expensive to be double-spent occasionally than to have a delay
Hi Bitcoin Devs,
We are writing to share with you a suggested improvement to the current
bitcoin core block building algorithm. In short, currently Bitcoin Core
uses a straightforward greedy algorithm which evaluates each
transaction’s effective fee rate in the context of its unconfirmed
ancestors
the miner fee:
>> ->
>> https://github.com/mycelium-com/wallet/blob/master/public/bitlib/src/main/java/com/mrd/bitlib/StandardTransactionBuilder.java#L334
>>
>> Does your simulation account for that?
>>
>> It might also be that the small UT
tx and we never spend
> them, bec. of pruning/privacy. Not sure how we could optimize that.
>
> Cheers,
> Daniel
>
> On 2016-09-21 14:58, Murch via bitcoin-dev wrote:
>> Hi,
>>
>> I'm currently compiling my Master's thesis about Coin Selection and my
&g
Hi,
I'm currently compiling my Master's thesis about Coin Selection and my
presentation proposal to Scaling Bitcoin has been accepted.
For my thesis, I have analyzed the Coin Selection problem, created a
framework to simulate wallet behavior on basis of a sequence of
payments, and have re-impleme
11 matches
Mail list logo