public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] Reusable payment codes
@ 2015-04-24 20:00 Justus Ranvier
  2015-04-24 20:58 ` Gregory Maxwell
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Justus Ranvier @ 2015-04-24 20:00 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1


https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki


This link contains an RFC for a new type of Bitcoin address called a
"payment code"


Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
addresses which provide useful features such as positively identifying
senders to recipients and automatically providing for transaction refunds.


Payment codes can be publicly advertised and associated with a real-life
identity without causing a loss of financial privacy.


Compared to stealth addresses, payment codes require less blockchain data
storage.


Payment codes require 65 bytes of OP_RETURN data per sender-recipient pair,
while stealth addresses require 40 bytes per transaction.


-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1


iQIcBAEBAgAGBQJVOqCRAAoJECpf2nDq2eYjluEP/RVJk+miDIihY4ilIvUbKvMd

JLLqHr7Q1dlZyMIG/UqVWdoP5hzg/16B+q2iAB9jXozPnrDp0mggBh6rIGroevAa

Kqfrs+Rrog1w9auhd67LWORDqav6YIrjTJIxdLxe11IEiq5rWbHPNUEDMzdEmHbz

QfTH7KWAP2BasO5ETXcfu6BcccrXZ3XOKLON2h3NGD/cEDizY+uT2k3QN54z+KxG

NB9scKbzVvsJwkyBrgbV+As9H3k6PnFsojYgAaE9gkp7D2+ahjzUiOH5rv6TbbYR

o2X5MOiTY2/YZEqZPG7IR03ZAgeLVCvXXysjPOfzUKbmTF4w849sm8BuhixzDXHo

2V/HHKoGclIohcODBCWi0tVQXshZt4QkCNJBW5o3nL6Nn2YOp6hmw8YKAHnw3E7h

/wIgk5f+NOLl/iIxoAxAdavEj5P6N4ic+OB6MAjnhEilWfBvCIpqWLGNvrtOhEa9

EnPHcgb4ILBu4OionJhsNpJ/O95C0OEypMm25MIS+rQcV4Uxe5IOS2OuT/GreLET

n/7Y0mJbqYbLBjVsfS+DNjvsgyJl5AxhcMrdVyXJjSYVcCoRhcoX5Ceidd+YkbHI

OMs5f63tM1Rgi/WY4Ct80SD5EbULZuu8j1KJ9HPGuMt081JSBH+L5isiKuazPeO+

SGApMBd4Q89fKzL2djae

=Dypr

-----END PGP SIGNATURE-----

[-- Attachment #2: Type: text/html, Size: 2586 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Reusable payment codes
@ 2015-04-27 14:53 Brian Deery
  2015-04-27 15:54 ` Justus Ranvier
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Brian Deery @ 2015-04-27 14:53 UTC (permalink / raw)
  To: bitcoin-development; +Cc: Justus Ranvier

[-- Attachment #1: Type: text/plain, Size: 2866 bytes --]

Hi Justus:

CC'ing mailing list because more bloom filter and HD wallet experts there
can chime in for some of these thoughts.  I refined some ideas we went over
earlier.

Here are some critiques/worries about the payment codes.

With identities explicitly tied to a payment code, bloom filter clients can
have identities tied to them.

1. There will be a 1:1 relationship between a payment code owner and their
identity.  Presumably the payment code would be strongly and publicly tied
to the identity.  This makes the notification address strongly tied to the
user.  An SPV client connecting to a full node who has a list of
notification address can tie an identity to a bloom filter and connecting
IP.

2. The client can use a bloom filter with a higher false positive rate.  An
active attacker can counter that by sending several payment codes to an
individual user.  The user would then add to their bloom filter all the
shared addresses between them and the attacker.  Even with a high false
positive filter, always matching all the attacker's payment codes would
strongly tie the user to the filter.



Here are some data savings and privacy addition ideas:

65 bytes -> 0 bytes extra.

1. Can you choose only even or odd DER encoding?  That would save you 1
byte.  This would probably throw out 50% of possible addresses though.
2. Can the chain code be fixed or derived from the x value?  Could the
chain value be the x value itself?  (The main question is can a
deterministic public seed be represented as a single 32 bit number?  Maybe
the chain code can be a constant.  Maybe it is ok since subsequent pubkeys
are derived from this.  I only know enough crypto to be dangerous.) That
would save you 32 bytes.  Someone who understands HD wallets would be
better to look at this one.  it would probably be a non-standard derivation.

That leaves you with 32 bytes to communicate to bootstrap the channel.

3: Since you are already looking at the pubkey of the transaction sending
the notification transaction, then you are assuming control of the sending
mechanism.  If you can be sure to use a disposable bitcoin address to send
the notification, then 1 more savings might be possible.  Also assuming the
above two points are possible.

Can you encode the "x value" into the signature's R value?  This would
basically make this transaction look like a standard bitcoin transaction
and gets rid of the op_return completely.



I still like the idea of a common meeting point, a la bitmessage.  The
receiver of the payment code would trial-decode all payment codes sent to a
common pre-specified dead drop address (perhaps a charity address).  "to
send me money, first donate to this charity of my choice."  This trades off
more work on the receivers part to get some privacy as to the number of
people interacting with that receiver.


-cheers
-Brian Deery

[-- Attachment #2: Type: text/html, Size: 3364 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2015-06-17  5:34 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-24 20:00 [Bitcoin-development] Reusable payment codes Justus Ranvier
2015-04-24 20:58 ` Gregory Maxwell
     [not found]   ` <CAHabJ+MtWJS=e3tkGih=xoP4ARgHe8X=D_p9OWTnRJi0z9epBw@mail.gmail.com>
2015-04-25  0:20     ` [Bitcoin-development] Fwd: " Justus Ranvier
     [not found]     ` <CAHabJ+Oabx80+_1KutfrPUt5QEnMivfNeeh4uJJJOsiHRQqSZw@mail.gmail.com>
2015-04-25  0:21       ` Justus Ranvier
     [not found] ` <1AE7B0A2-90EE-42EE-9D30-4DC1B5892E53@newcastle.ac.uk>
     [not found]   ` <CAHabJ+NDqMN-rQ1BN1TfOjGLQHH-3Wd28LdoF95Agn4HdRrThg@mail.gmail.com>
2015-04-25  0:22     ` Justus Ranvier
     [not found]       ` <CAAS2fgSAT2otym64oUACpWD8jWLAB6dBusONn-WUx2DK59SB5w@mail.gmail.com>
2015-04-25  2:34         ` Justus Ranvier
2015-04-26 12:58           ` Mike Hearn
2015-04-26 14:50             ` Justus Ranvier
2015-06-16 16:26 ` [Bitcoin-development] " odinn
2015-06-16 17:46   ` Peter Todd
2015-06-17  5:34     ` odinn
2015-04-27 14:53 Brian Deery
2015-04-27 15:54 ` Justus Ranvier
2015-04-27 16:46 ` Mike Hearn
2015-04-27 17:02   ` Justus Ranvier
2015-04-28 13:53     ` Justus Ranvier
2015-04-29 23:44 ` Justus Ranvier

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox