📅 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>;
Andreas Petersson [ARCHIVE] /
npub10z…qsg9a
2023-06-07 15:38:58
in reply to nevent1q…9cuw
Author Public Key
npub10zyxjrelgpp85qc93pnt8e4yx0jsxm27sn9lsypkhlrttjpmjktqkqsg9aPublished at
2023-06-07 15:38:58Event JSON
{
"id": "38995daea69ac09f96bbb2cb282e182a8e868060dacff47033798799c8cd9c92",
"pubkey": "7888690f3f40427a03058866b3e6a433e5036d5e84cbf81036bfc6b5c83b9596",
"created_at": 1686152338,
"kind": 1,
"tags": [
[
"e",
"6b4025f674cbd304cabd44490b09b3ceb927f752f6a9f4513b25fefc95bdc008",
"",
"root"
],
[
"e",
"a0557e9ed1bc64d46e61c68e28e07090f71bef7f549a96f96bd154186e92e8c7",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2015-06-19\n📝 Original message:I have some experience here. If you are seriously suggesting these\nmeasures, you might as well kill retail transactions altogether.\n\nIn practice, if a retail place starts to accept bitcoin they have a\nsimilar situation as with cash, only that the fraud potential is much\nlower. (e.g. 100-dollar bill for a sandwich might turn out fake later)\nand the fraud frequency is also much lower.\n\n0-conf concerns were never a problem in practice. except for 2-way atms\ni have never heard of a problem that was caused by double spends.\nwhile adding these measures is generally positive, requiring them means\nexcluding 99.9% of the potential users. so you might as well not do it.\n\nRBF as implemented by F2Pool just flat out lowers Bitcoins utility\nvalue. So it's a bad thing.\n\nfor any online or automated system, waiting for a handful of\nconfirmations was always recommended practice.\n\nAm 19.06.2015 um 22:39 schrieb Matt Whitlock:\n\u003e Retail POS merchants probably should not be accepting vanilla Bitcoin\n\u003e payments, as Bitcoin alone does not (and cannot) guarantee the\n\u003e irreversibility of a transaction until it has been buried several\n\u003e blocks deep in the chain. Retail merchants should be requiring a\n\u003e co-signature from a mutually trusted co-signer that vows never to sign\n\u003e a double-spend. \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: 0xAA4EDEEF.asc\nType: application/pgp-keys\nSize: 998 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/84f25498/attachment.bin\u003e",
"sig": "37b96610601645e88bca8e305ef4fb9d268d91469d5a93fdf143eb2af7973152fdb501b8378f01b08285f9bc61a89926d3ffb6aa88057a43c3c843dafdf9681b"
}