Hi Dario,
Thanks for providing more thoughts to the discussion!
> Notice that #26323 (option 5 in the OP) has the advantage of getting us
to a
> reliable full-RBF network the fastest (in particular, much faster than the
> current opt-in deployment) while not threatening zero-conf applications
> u
Hi woltx,
Thanks for the response.
> Using all inputs, it becomes possible to use SP addresses in coinjoins as
> long as all participants agree.
> More information:
> https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inputs
Using new addresses and SP address
Hi Dave,
> One way to address this risk is by turning it into a certainty. If the
price of BTC increases between when the invoice is generated and when a
transaction is included in a block, give the customer a future purchase
credit equal in value to the difference between the price they paid
On 2022-10-19 04:29, Sergej Kotliar via bitcoin-dev wrote:
The biggest risk
in accepting bitcoin payments is in fact not zeroconf risk (it's
actually quite easily managed), it's FX risk as the merchant must
commit to a certain BTCUSD rate ahead of time for a purchase. Over
time some transactions
Hi /dev/fd0
I haven't accessed ML for a while.
1) All inputs being used sounds good although I do not understand how it would
benefit coinjoin.
Using all inputs, it becomes possible to use SP addresses in coinjoins as long
as all participants agree.
More information:
https://gist.github.com/Ru
