Justus Ranvier [ARCHIVE] on Nostr: š Original date posted:2015-04-24 š Original message:I have pushed an updated ...
š
Original date posted:2015-04-24
š Original message:I have pushed an updated version of the proposal which incorporates some of
the received feedback and adds a note about the consequences of sharing a
payment code-enabled walled on multiple devices:
https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521
On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier <justus.ranvier at monetas.net
> wrote:
>
>
> On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>
>> So this requires making dust payments to a constantly reused address
>> in order to (ab)use the blockchain as a messaging layer.
>>
>> Indeed, this is more SPV compatible; but it seems likely to me that
>> _in practice_ it would almost completely undermine the privacy the
>> idea hoped to provide; because you'd have an observable linkage to a
>> highly reused address.
>>
>
> I agree that the output associated with notification transactions would
> require special handling to avoid privacy leaks. At a minimum they'd
> require mixing or being donated to miners as a transaction fee.
>
>
>>
>> It would also more than double the data sent for the application where
>> 'stealth addresses' are most important: one-time anonymous donations
>> (in other contexts; you have two way communication between the
>> participants, and so you can just given them a one off address without
>> singling in the public network.)
>>
>
> Communication is only one way, except for the case in which the recipient
> wants to send a refund. Assuming no refund and only a single anonymous
> donation in the lifetime of the sender's identity, payment codes would
> require 65 bytes vs 40 bytes for stealth addresses.
>
> As soon as the sender sends more than one donation to the same recipient,
> payment codes show an space advantage over stealth addresses.
>
> This kind of binding was intentionally designed out of the stealth
>>
> address proposal; I think this scheme can be made to work without any
>> increase in size by reusing the payment code as the ephemeral public
>> key (or actually being substantially smaller e.g. use the shared
>> secret as the chain code, but I should give it more thought)
>>
>
> With 97 byte standard OP_RETURN values the ephemeral public
> key could be appended to the chain code, but that's undesirable for other
> reasons.
>
> This is fundamentally more expensive to compute; please don't specify
>> "uncompressed".
>>
>
> Taking the SHA512 of something less than 512 bits seemed wrong.
>
>
>> This appears incompatible with multisignature; which is unfortunate.
>>
>
> I agree. I could not find a straightforward way to express a
> multisignature payment code in less than 80 bytes.
>
>
>> I'm disappointed that there isn't any thought given to solving the
>> scanning privacy without forcing non-private pure-overhead messaging
>> transactions on heavily reused addresses. Are you aware of the IBE
>> approach that allows someone to request a third party scan for them
>> with block by block control over their delegation of scanning?
>>
>
> I suspect this is a case where we just can't have all the features we want.
>
> In this proposal I optimized for non-reliance on third party services and
> a guaranteed ability to recover spendable funds from a seed backup.
>
> Gaining those two features resulted in some tradeoffs as you noted, but I
> think there are enough benefits to make them worthwhile.
>
> In particular, payment codes could be the basis for a Heartbleed-free
> payment protocol that can positively identify customers and automatically
> provide refund capabilities in a merchant-customer relationship. A merchant
> only requires one payment code which they can safely use for all their
> customers, meaning they only ever need to associate 65 bytes with their
> identity to allow customers to make sure they are paying the right entity.
>
> Exchanges could restrict bitcoin withdrawals to a single payment code
> known to be associated with their identified customer. This would make
> thefts easier (without involving address reuse as in locking withdrawals to
> a single P2PKH address).
>
> In some jurisdictions the ability to prove that withdrawals are sent to a
> positively-identified party, rather than arbitrary third parties, might
> move some Bitcoin businesses out of money transmitter territory into less
> onerous regulatory situations.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150425/1536c9c0/attachment.html>;
š Original message:I have pushed an updated version of the proposal which incorporates some of
the received feedback and adds a note about the consequences of sharing a
payment code-enabled walled on multiple devices:
https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521
On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier <justus.ranvier at monetas.net
> wrote:
>
>
> On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>
>> So this requires making dust payments to a constantly reused address
>> in order to (ab)use the blockchain as a messaging layer.
>>
>> Indeed, this is more SPV compatible; but it seems likely to me that
>> _in practice_ it would almost completely undermine the privacy the
>> idea hoped to provide; because you'd have an observable linkage to a
>> highly reused address.
>>
>
> I agree that the output associated with notification transactions would
> require special handling to avoid privacy leaks. At a minimum they'd
> require mixing or being donated to miners as a transaction fee.
>
>
>>
>> It would also more than double the data sent for the application where
>> 'stealth addresses' are most important: one-time anonymous donations
>> (in other contexts; you have two way communication between the
>> participants, and so you can just given them a one off address without
>> singling in the public network.)
>>
>
> Communication is only one way, except for the case in which the recipient
> wants to send a refund. Assuming no refund and only a single anonymous
> donation in the lifetime of the sender's identity, payment codes would
> require 65 bytes vs 40 bytes for stealth addresses.
>
> As soon as the sender sends more than one donation to the same recipient,
> payment codes show an space advantage over stealth addresses.
>
> This kind of binding was intentionally designed out of the stealth
>>
> address proposal; I think this scheme can be made to work without any
>> increase in size by reusing the payment code as the ephemeral public
>> key (or actually being substantially smaller e.g. use the shared
>> secret as the chain code, but I should give it more thought)
>>
>
> With 97 byte standard OP_RETURN values the ephemeral public
> key could be appended to the chain code, but that's undesirable for other
> reasons.
>
> This is fundamentally more expensive to compute; please don't specify
>> "uncompressed".
>>
>
> Taking the SHA512 of something less than 512 bits seemed wrong.
>
>
>> This appears incompatible with multisignature; which is unfortunate.
>>
>
> I agree. I could not find a straightforward way to express a
> multisignature payment code in less than 80 bytes.
>
>
>> I'm disappointed that there isn't any thought given to solving the
>> scanning privacy without forcing non-private pure-overhead messaging
>> transactions on heavily reused addresses. Are you aware of the IBE
>> approach that allows someone to request a third party scan for them
>> with block by block control over their delegation of scanning?
>>
>
> I suspect this is a case where we just can't have all the features we want.
>
> In this proposal I optimized for non-reliance on third party services and
> a guaranteed ability to recover spendable funds from a seed backup.
>
> Gaining those two features resulted in some tradeoffs as you noted, but I
> think there are enough benefits to make them worthwhile.
>
> In particular, payment codes could be the basis for a Heartbleed-free
> payment protocol that can positively identify customers and automatically
> provide refund capabilities in a merchant-customer relationship. A merchant
> only requires one payment code which they can safely use for all their
> customers, meaning they only ever need to associate 65 bytes with their
> identity to allow customers to make sure they are paying the right entity.
>
> Exchanges could restrict bitcoin withdrawals to a single payment code
> known to be associated with their identified customer. This would make
> thefts easier (without involving address reuse as in locking withdrawals to
> a single P2PKH address).
>
> In some jurisdictions the ability to prove that withdrawals are sent to a
> positively-identified party, rather than arbitrary third parties, might
> move some Bitcoin businesses out of money transmitter territory into less
> onerous regulatory situations.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150425/1536c9c0/attachment.html>;