<unnamed>

Public Key

npub10zyxjrelgpp85qc93pnt8e4yx0jsxm27sn9lsypkhlrttjpmjktqkqsg9a

Profile Code

nprofile1qqs83zrfpul5qsn6qvzcse4nu6jr8egrd40gfjlczqmtl344eqaet9spzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmvr8v2wy

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:38:58 CEST

- reply

📅 Original date posted:2015-06-19
📝 Original message:I have some experience here. If you are seriously suggesting these
measures, you might as well kill retail transactions altogether.
In practice, if a retail place starts to accept bitcoin they have a
similar situation as with cash, only that the fraud potential is much
lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
and the fraud frequency is also much lower.
0-conf concerns were never a problem in practice. except for 2-way atms
i have never heard of a problem that was caused by double spends.
while adding these measures is generally positive, requiring them means
excluding 99.9% of the potential users. so you might as well not do it.
RBF as implemented by F2Pool just flat out lowers Bitcoins utility
value. So it's a bad thing.
for any online or automated system, waiting for a handful of
confirmations was always recommended practice.
Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
> Retail POS merchants probably should not be accepting vanilla Bitcoin
> payments, as Bitcoin alone does not (and cannot) guarantee the
> irreversibility of a transaction until it has been buried several
> blocks deep in the chain. Retail merchants should be requiring a
> co-signature from a mutually trusted co-signer that vows never to sign
> a double-spend.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xAA4EDEEF.asc
Type: application/pgp-keys
Size: 998 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/84f25498/attachment.bin>