📅 Original date posted:2014-05-12
📝 Original message:Just a thought. Using the payment protocol for stealth would mean we
would likely have to return to backing up wallets all the time would it not?
The nonces cannot be derived from your wallet seed and, since they
aren't in the blockchain, would have to be stored in your wallet. I
suppose they could be stored on the server, but you would probably want
a backup for that anyway. So we would end up having to back up all the
time, something we're trying to get away from. Am I correct about this?
On 05/09/2014 02:38 PM, Pieter Wuille wrote:
> On Fri, May 9, 2014 at 8:13 PM, Peter Todd <pete at petertodd.org> wrote:
>> I don't think we're going to find that's practical unfortunately due to
>> change. Every payment I make ties up txouts, so if we try to base the
>> atomicity of payments on whether or not the payee decides to broadcast
>> the transaction the payor is stuck with txouts that they can't use until
>> the payee makes up their mind. That leads to lots and lots of nasty edge
>> cases.
> I haven't talked much about it except for on IRC, but my idea was this:
> * PaymentACK messages become signed (with the same key as the payment
> request, or using some delegation mechanism, so that the same key
> doesn't need to remain online).
> * Instead of a full Bitcoin transaction, a Payment message contains a
> scriptSig-less Bitcoin transaction + a limit on its byte size (and
> perhaps a limit on its sigop count).
> * The sender sends such a Payment to the receiver before actually
> signing the transaction (or at least, before revealing the signed
> form).
> * The receiver only ACKs if the transaction satisfies the request, is
> within time limits, isn't unlikely to confirm.
> * If the sender likes the ACK (the refund and memo fields are intact,
> the transaction isn't changed, the signature key is valid, ...), he
> either sends the full transaction (with receiver taking responsibility
> for broadcasting) or broadcasts it himself.
>
> Together, this means that a paymentACK + a confirmed matching Bitcoin
> transaction can count as proof of payment. Both parties have a chance
> to disagree with the transaction, and are certain all communicated
> data (apart from transaction signatures) in both directions happened
> correctly before committing. It would completely remove the chance
> that the Bitcoin transaction gets broadcast without the receiver
> liking it (for legitimate or illegitimate reasons), or without the
> backchannel functioning correctly.
>
> It's also compatible with doing multiple payments in one Bitcoin
> transaction - you can ask for ACKs from multiple parties before
> signing the transaction.
>
> Of course, the sender can still withhold the signed transaction (in
> which case nothing happened, but we probably need a second timeout),
> or the receiver can always claim to have never received the
> transaction. The sender can broadcast the transaction himself in order
> to prevent that, after obtaining an ACK.
>
Chris Pacia [ARCHIVE] /
npub1jp…kn8jw
2023-06-07 15:21:12
in reply to nevent1q…wqze
Author Public Key
npub1jp0jnnq2jxcjy76nrt5dssvmpynt4f9psdelp3vxj0y0xtpxl7jqhkn8jwPublished at
2023-06-07 15:21:12Event JSON
{
"id": "9c15e0e4bfd6d6bad9269454196cf8f1eb993ebe4f3adb0f2326cf427d1bac80",
"pubkey": "905f29cc0a91b1227b531ae8d8419b0926baa4a18373f0c58693c8f32c26ffa4",
"created_at": 1686151272,
"kind": 1,
"tags": [
[
"e",
"8514559181783b25e020bd1cec2b637ea86474de420a1085a131f4b38759b722",
"",
"root"
],
[
"e",
"24845a560088094751d59ea0a12d0b55de43ae7602ec5d1e8a36323e409b6a09",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2014-05-12\n📝 Original message:Just a thought. Using the payment protocol for stealth would mean we\nwould likely have to return to backing up wallets all the time would it not?\n\nThe nonces cannot be derived from your wallet seed and, since they\naren't in the blockchain, would have to be stored in your wallet. I\nsuppose they could be stored on the server, but you would probably want\na backup for that anyway. So we would end up having to back up all the\ntime, something we're trying to get away from. Am I correct about this?\n\nOn 05/09/2014 02:38 PM, Pieter Wuille wrote:\n\u003e On Fri, May 9, 2014 at 8:13 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e\u003e I don't think we're going to find that's practical unfortunately due to\n\u003e\u003e change. Every payment I make ties up txouts, so if we try to base the\n\u003e\u003e atomicity of payments on whether or not the payee decides to broadcast\n\u003e\u003e the transaction the payor is stuck with txouts that they can't use until\n\u003e\u003e the payee makes up their mind. That leads to lots and lots of nasty edge\n\u003e\u003e cases.\n\u003e I haven't talked much about it except for on IRC, but my idea was this:\n\u003e * PaymentACK messages become signed (with the same key as the payment\n\u003e request, or using some delegation mechanism, so that the same key\n\u003e doesn't need to remain online).\n\u003e * Instead of a full Bitcoin transaction, a Payment message contains a\n\u003e scriptSig-less Bitcoin transaction + a limit on its byte size (and\n\u003e perhaps a limit on its sigop count).\n\u003e * The sender sends such a Payment to the receiver before actually\n\u003e signing the transaction (or at least, before revealing the signed\n\u003e form).\n\u003e * The receiver only ACKs if the transaction satisfies the request, is\n\u003e within time limits, isn't unlikely to confirm.\n\u003e * If the sender likes the ACK (the refund and memo fields are intact,\n\u003e the transaction isn't changed, the signature key is valid, ...), he\n\u003e either sends the full transaction (with receiver taking responsibility\n\u003e for broadcasting) or broadcasts it himself.\n\u003e\n\u003e Together, this means that a paymentACK + a confirmed matching Bitcoin\n\u003e transaction can count as proof of payment. Both parties have a chance\n\u003e to disagree with the transaction, and are certain all communicated\n\u003e data (apart from transaction signatures) in both directions happened\n\u003e correctly before committing. It would completely remove the chance\n\u003e that the Bitcoin transaction gets broadcast without the receiver\n\u003e liking it (for legitimate or illegitimate reasons), or without the\n\u003e backchannel functioning correctly.\n\u003e\n\u003e It's also compatible with doing multiple payments in one Bitcoin\n\u003e transaction - you can ask for ACKs from multiple parties before\n\u003e signing the transaction.\n\u003e\n\u003e Of course, the sender can still withhold the signed transaction (in\n\u003e which case nothing happened, but we probably need a second timeout),\n\u003e or the receiver can always claim to have never received the\n\u003e transaction. The sender can broadcast the transaction himself in order\n\u003e to prevent that, after obtaining an ACK.\n\u003e",
"sig": "5f7168072b48a11dfc5d64f98c373deb5fe8b2aaa8b7bd7f4e318ba771f2d3649afe5f9a57a8e6c3e986e3f8955416693cf3f17c1852b332715bb01d57e89641"
}