📅 Original date posted:2015-06-19
📝 Original message:> What retail needs is escrowed microchannel hubs (what lightning provides,
for example), which enable untrusted instant payments. Not reliance on
single-signer zeroconf transactions that can never be made safe.
They don't need to be made cryptographically safe, they just have to be
safer than, for instance, credit card payments that can be charged back. As
long as it's reasonably good in practice, that's fine.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> What retail needs is escrowed microchannel hubs (what lightning provides,
> for example), which enable untrusted instant payments. Not reliance on
> single-signer zeroconf transactions that can never be made safe.
>
> On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson <andreas at petersson.at>
> wrote:
>
>> 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.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/8f05595a/attachment.html>;
Aaron Voisine [ARCHIVE] /
npub18g…knkzl
2023-06-07 15:38:59
in reply to nevent1q…u8gp
Author Public Key
npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzlPublished at
2023-06-07 15:38:59Event JSON
{
"id": "5cf8e78ffaf0a8bf858424593ce70294debbfdf0e6637fd070b4b220c877e887",
"pubkey": "3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3",
"created_at": 1686152339,
"kind": 1,
"tags": [
[
"e",
"6b4025f674cbd304cabd44490b09b3ceb927f752f6a9f4513b25fefc95bdc008",
"",
"root"
],
[
"e",
"9e024ff2e4f8af451b0ac1f508532e51a8395422bd6aea4824ffded5ee81e993",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2015-06-19\n📝 Original message:\u003e What retail needs is escrowed microchannel hubs (what lightning provides,\nfor example), which enable untrusted instant payments. Not reliance on\nsingle-signer zeroconf transactions that can never be made safe.\n\nThey don't need to be made cryptographically safe, they just have to be\nsafer than, for instance, credit card payments that can be charged back. As\nlong as it's reasonably good in practice, that's fine.\n\n\nAaron Voisine\nco-founder and CEO\nbreadwallet.com\n\nOn Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\nwrote:\n\n\u003e What retail needs is escrowed microchannel hubs (what lightning provides,\n\u003e for example), which enable untrusted instant payments. Not reliance on\n\u003e single-signer zeroconf transactions that can never be made safe.\n\u003e\n\u003e On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson \u003candreas at petersson.at\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e I have some experience here. If you are seriously suggesting these\n\u003e\u003e measures, you might as well kill retail transactions altogether.\n\u003e\u003e\n\u003e\u003e In practice, if a retail place starts to accept bitcoin they have a\n\u003e\u003e similar situation as with cash, only that the fraud potential is much\n\u003e\u003e lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)\n\u003e\u003e and the fraud frequency is also much lower.\n\u003e\u003e\n\u003e\u003e 0-conf concerns were never a problem in practice. except for 2-way atms\n\u003e\u003e i have never heard of a problem that was caused by double spends.\n\u003e\u003e while adding these measures is generally positive, requiring them means\n\u003e\u003e excluding 99.9% of the potential users. so you might as well not do it.\n\u003e\u003e\n\u003e\u003e RBF as implemented by F2Pool just flat out lowers Bitcoins utility\n\u003e\u003e value. So it's a bad thing.\n\u003e\u003e\n\u003e\u003e for any online or automated system, waiting for a handful of\n\u003e\u003e confirmations was always recommended practice.\n\u003e\u003e\n\u003e\u003e Am 19.06.2015 um 22:39 schrieb Matt Whitlock:\n\u003e\u003e \u003e Retail POS merchants probably should not be accepting vanilla Bitcoin\n\u003e\u003e \u003e payments, as Bitcoin alone does not (and cannot) guarantee the\n\u003e\u003e \u003e irreversibility of a transaction until it has been buried several\n\u003e\u003e \u003e blocks deep in the chain. Retail merchants should be requiring a\n\u003e\u003e \u003e co-signature from a mutually trusted co-signer that vows never to sign\n\u003e\u003e \u003e a double-spend.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/8f05595a/attachment.html\u003e",
"sig": "8327029f3c7ccaff358047dcb9ce199b17b3de34679d6e8f63310870f18edb0a7a32ba4c7d1b29b25d4196b4ece0bfd2d7a9d97858f7741a82ba1ade77a87aeb"
}