📅 Original date posted:2013-12-02
📝 Original message:First time posting to this mailing list so feel free to ignore me if
this is a stupid idea.
On Mon, Dec 2, 2013 at 3:49 AM, Mike Hearn <mike at plan99.net> wrote:
>
> We need to get away from the notion of senders attaching fees anyway. This is the wrong
> way around because it’s the recipient who cares about double spending risk, not the sender.
>
It seems to me that a common problem currently revolves around
accepting transactions in
retail scenarios, such as paying for a sandwich from Subway. A
solution could be to give the
vendor responsibility for setting the fee, which means they can choose
the trade-off that works
best for them in terms of fee size vs. speed of processing.
Idea:
Add a "fee" parameter to the payment URI specification.
When processing the transaction, the customer's UI should show only
the total price, including
both the transfer amount and the fee. The vendor only accepts the
transaction if the customer
uses the right amount and fee. If the fee is too small (for example,
the user might be using an
older wallet and has selected a fee of zero), the vendor can issue a
refund transaction
immediately and tell the user to try again.
Pros:
- could easily be implemented immediately
- old wallets would still be supported by just manually entering the
fee as users do now
- no greater risk of double spending on either side
- maintains the distributed nature of the system
- relies on humans to judge the fee (who are much less likely to
spiral infinitely upwards)
- flexible enough to support varying sizes of transaction and varying
degrees of security
Cons
- requires the vendor to have sufficient understanding of Bitcoin to
make the trade-off
- doesn't solve the problem of selecting a fee for transactions
between individuals/laymen
- doesn't solve fee selection for automated transactions such as
mixing/de/refragmentation
Thoughts?
Patrick Mead [ARCHIVE] /
npub1le…q4t7s
2023-06-07 15:10:05
in reply to nevent1q…yjf9
Author Public Key
npub1lekc3nrsuh2zmqda70jx8mspqyd5mftar9zvd5lwxl9fszagstfq7q4t7sSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:10:05Event JSON
{
"id": "d87de409272c159d24e3a8d63b97018d66c2a029a502b75e5cbfd73c941bb669",
"pubkey": "fe6d88cc70e5d42d81bdf3e463ee01011b4da57d1944c6d3ee37ca980ba882d2",
"created_at": 1686150605,
"kind": 1,
"tags": [
[
"e",
"f082c8a0fa2ac5febf83583d19b2776fdb1875fb3ab2eae661676f17ee054405",
"",
"root"
],
[
"e",
"39ae21fbd4fbfb0bf16a5054d8980f606a9639e1977a6ae11b56499c77933996",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2013-12-02\n📝 Original message:First time posting to this mailing list so feel free to ignore me if\nthis is a stupid idea.\n\n\nOn Mon, Dec 2, 2013 at 3:49 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\n\u003e We need to get away from the notion of senders attaching fees anyway. This is the wrong\n\u003e way around because it’s the recipient who cares about double spending risk, not the sender.\n\u003e\n\n\nIt seems to me that a common problem currently revolves around\naccepting transactions in\nretail scenarios, such as paying for a sandwich from Subway. A\nsolution could be to give the\nvendor responsibility for setting the fee, which means they can choose\nthe trade-off that works\nbest for them in terms of fee size vs. speed of processing.\n\nIdea:\nAdd a \"fee\" parameter to the payment URI specification.\nWhen processing the transaction, the customer's UI should show only\nthe total price, including\nboth the transfer amount and the fee. The vendor only accepts the\ntransaction if the customer\nuses the right amount and fee. If the fee is too small (for example,\nthe user might be using an\nolder wallet and has selected a fee of zero), the vendor can issue a\nrefund transaction\nimmediately and tell the user to try again.\n\nPros:\n- could easily be implemented immediately\n- old wallets would still be supported by just manually entering the\nfee as users do now\n- no greater risk of double spending on either side\n- maintains the distributed nature of the system\n- relies on humans to judge the fee (who are much less likely to\nspiral infinitely upwards)\n- flexible enough to support varying sizes of transaction and varying\ndegrees of security\n\nCons\n- requires the vendor to have sufficient understanding of Bitcoin to\nmake the trade-off\n- doesn't solve the problem of selecting a fee for transactions\nbetween individuals/laymen\n- doesn't solve fee selection for automated transactions such as\nmixing/de/refragmentation\n\n\nThoughts?",
"sig": "f424f64617a1a6f596ac4c0c24d16260cac1db71804a248cbc629d4909f68e36e19e12a467aeea1dbcde8bf52ebd5c8ee380a840f1993b482b57476d9b224967"
}