Re: [Bitcoin-development] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is very well done. Have you seen this discussion that I started regarding BIP 63? https://bitcointalk.org/index.php?topic=1083961.0 I have no response from Peter Todd back on it other than my time is better spent focusing on more fundemental issues and I've also got no-one interested in funding stealth address development right now, when several people (myself included) offered to send donations to see the BIP (63) advance, no donation address was posted, so... waiting for him to act on that. I'm definitely supportive of seeing what you've written up here as Reusable payment codes move to draft in https://github.com/bitcoin/bips When you can, please write up something on bitcointalk as well. On 04/24/2015 01:00 PM, Justus Ranvier wrote: Hash: SHA1 https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.m ediawiki 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. -- - One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development - -- http://abis.io ~ a protocol concept to enable decentralization and expansion of a giving economy, and a new social good https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVgE4fAAoJEGxwq/inSG8CjgkH/i0aX4aJaOjrbI2xzWbPeL1T /APSvSqV0D610ljbw/MuRRFVagnK3lCs73fYolKw9uFG0cnwhIWJ53mCqPWhM5nL kIejDTHr9jQ2tbXrU2L481Oat1Z6vtdQj7LolXFfD3Ktqz+sqp//gBaC9EEZ5nOq 4oz71Am58pf8+XGhtJk0+4XDXzFNd71bKKY+nMf9f3bwqNX93jHiF48hXwijFPC4 MOZmYRh3Sf5LAVP5p1JY3aJRQv4M/W0L2RDC+GW8Ol997etQSGGLhESihNNPw1m8 GEqJLBmUBkavzsRpZ009czfzL7EiCwsMbOrVw918o2Y9NnVpY9a9cBNB+UJgCmk= =wAGz -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reusable payment codes
On Tue, Jun 16, 2015 at 09:26:07AM -0700, odinn wrote: This is very well done. Have you seen this discussion that I started regarding BIP 63? https://bitcointalk.org/index.php?topic=1083961.0 I have no response from Peter Todd back on it other than my time is better spent focusing on more fundemental issues and I've also got no-one interested in funding stealth address development right now, when several people (myself included) offered to send donations to see the BIP (63) advance, no donation address was posted, so... waiting for him to act on that. Sorry, but I'm looking at the huge amount of work that I'll likely have responding to the blocksize issue, so I think I'm inclined to shelve work on BIP63 for now. Feel free to take it up; a (=2)-part standard describing the resuable codes aspect, and separately how the ephemeral key is transmitted to the recipient makes sense to me. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter, my response below On 06/16/2015 10:46 AM, Peter Todd wrote: On Tue, Jun 16, 2015 at 09:26:07AM -0700, odinn wrote: This is very well done. Have you seen this discussion that I started regarding BIP 63? https://bitcointalk.org/index.php?topic=1083961.0 I have no response from Peter Todd back on it other than my time is better spent focusing on more fundemental issues and I've also got no-one interested in funding stealth address development right now, when several people (myself included) offered to send donations to se e the BIP (63) advance, no donation address was posted, so... waiting for him to act on that. Sorry, but I'm looking at the huge amount of work that I'll likely hav e responding to the blocksize issue, so I think I'm inclined to shelve work on BIP63 for now. I seriously find this pretty sad... you said that paying rent was an issue and your time was better spent on more fundamental issues... but the very least you could do is post a donation address... Is there someone who was working with you closely on the concept who could take it up since you are not going to be working on it? Feel free to take it up; a (=2)-part standard describing the resuable codes aspect, and separately how the ephemeral key is transmitted to t he recipient makes sense to me. I don't want to camp on Justus's thread on reusable payment codes ~ but on the subject of BIP 63, it just did make sense to mention... so if someone does have interest in working on it... please go to https://bitcointalk.org/index.php?topic=1083961.0 and reply there. - -- http://abis.io ~ a protocol concept to enable decentralization and expansion of a giving economy, and a new social good https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVgQbMAAoJEGxwq/inSG8CD8gH/3jV+mLO9qv3t6JFxIvLMPtr slGbymQtuqfAC09b6ybx3p6u9I1o1Nb3IgK1riu/Z3AzHxlnuYVUxN3N5ns0zGnx F2WXs2suEa20YJkQ6dxZWLdNBjnUIEGGgXAit8X21LqVsqPfeZcocOWSeRDlePhk /HRFLVtMehqfqjbuFAaAewVZUyT4Bn+3IU74krqR3e3YA00/ym1C5xCE3/kHvKIL UF8EW9GgVYKuoyQdH3ICDwjiudwPOwIC4Ry0huaJgla43122RkwqYB+5kVr1583u dx3VW8vW8HyQZJF+vb8d3F57R6FC6zYtFhCe0IzDIh+6xQxStk5zosMNIrtPKp4= =h8Ib -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/27/2015 02:53 PM, Brian Deery wrote: 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. I've updated the proposal to provide for alternate methods of notification that can be used *in addition to* notification transactions. This frees the sender from constantly monitoring an address known to be associated with their identity, although they should check it periodically since not all senders will be capable of using every type of alternate notification method. I defined a Bitmessage notification method as an example; more can be added if required. https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVQWzPAAoJECpf2nDq2eYj8uAP/RsP050K9z8oDGy0KO+zjFwM iNzlsQaPY8kmR2k2oLXJp1n4QZIQAZly+vxjBZnOWXwAhrBcvnhNBvqdigwZYg3B oGyvGvArzkve86Ke1WF1hZEAvml3cmQ5jxYKMlwhzRPcHq2kwznw+5jRuTbf1JbE PxY5pOfnZ9ADVF5FkLR2KwBNvGA83Cle01hKd0eB6Omlb6azKDBXUqfzPPpB4lmp A8D0P3zkayzBYIiybUExfPJHUthd5wXL/TLwFkysPV7SnJE64C6Q2StD4wUtNQRS LDOw37RwhMx2Oz2YH3Ywi6w5tqYQP4LEWBuFb+LOqqphpV/FpFDl/Uznos00pz61 V9x2wrfg+MQnYk5/VIjPQxqvRsiu8yg4c2x0v+KIIMsuXKEPRFxaSS3DoaWUa1Jy +WDobHndIDw1TDqctP8LIiZ7zbWNYKJ4HgUaacHvTiA7TrJXi1KHo2b1pmnTbKhv fdHbjzd8UiMED6qeyrz1gGhjC2uSTwjZAmbBkCJccOGsrILoV1fifUW+de8qsBMH 6w6RiDwfeY2fHJHBS6O2Nhfk3OE5JaCWvy727ZXEq8lQ6dW0GOZvXg7INaktLagC tqvg85J5eCm7X8xQ33vgx8q2xt+IriMI2UnTILtb2H8XSiMRQSP7XfWDMfVGu4pb xbGZKbNS4WS+2FFKM4DK =6l99 -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The notification transactions are a pain point when it comes to privacy, and yet they must exist in order to to ensure that nobody can lose their money as long as they back up their wallet seed. They could be treated as a backup, however, that clients would not normally rely upon -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVP5DDAAoJECpf2nDq2eYjdLsQAJ/nZKFavcJnCMUQ8hKp6dRq 2+7bAVIWYHuOV6sv/hvG2NaP3u24NYZ/Ji0oD3UAmkJxw9lsZuowwBBs+YAs6JAW KHTl3QtwBh0IP/V90JOZ5Yn72YWXDsNbqy7R3JhEDKOu2wVeiLqWZ2EDgGwiZ0/k aXFJbcVZEKttWYCNoZi0yRMH+S9gbi0LgOwvK9mRzF9IRz07SM1iKQeKPsW1X1UM KNeikFROMS7dHTO5HRGyFcTSwhUf8RJq2kea+4sJtj8Vlb5rURuJanL3Fav+ZZjr RWYubLp9EUrDMm9bciygL8+MKPas8hedHSW2JhjkshWYC/NoCXLBT6SGrrbj2SKL zGGeLYknjwgLTCstKSQlXW3J/xcSFwBztr//o95SwRoIKI7jpuOE6cPfUZVEuTsU Zm7IWuRw/1MMDF89gCtDkBJcX2mTARjiii1Hg0+7vCv6Q/fVgTNUvWEKeNtCNZjh wOiwd4eP1gY4CwX68c+8CfF+NOSXImJTspZJvDQcTge1/bQJNOBn+cMYxjBcJsqL ZUOvkWJqwiFERW7vjMhOVpqIyO38UluwsWgp7nlMl/npfv0ZDIrOqZrswHSTqfdc P8gSaqvpc6cMaLL/ijvOtORkVB9ZlLmlTv6mIYWHeKEf6PjIOZEb2B75zPHFAvrz TKLxjvWgvSJ4l5PrkCFA =1Id2 -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reusable payment codes
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 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reusable payment codes
1. There will be a 1:1 relationship between a payment code owner and their identity. Bear in mind, the spec defines identity to mean: *Identity is a particular extended public/private key pair. * So that's not quite what is meant normally by identity. It's not a government / real name identity or an email address or phone number kind of identity. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/27/2015 04:46 PM, Mike Hearn wrote: So that's not quite what is meant normally by identity. It's not a government / real name identity or an email address or phone number kind of identity. I expect that mappings would begin to develop between payment codes and government / real name identities, at least as far as that businesses which are required to collect that kind of information would associate it with the payment code(s) known to be used by their customers for their own use. I proposed payment codes in this form because I'd rather see that kind of mapping be limited to the application layer and kept away from the blockchain/network layer. Even if it makes certain kind of application-layer distasteful behavior easier, it's a good trade if doing so can simultaneously provide resistance to graph analysis and make transaction-level censorship more difficult. - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVPmusAAoJECpf2nDq2eYjhxIP/3Jw9f6kcEsdFTXouQ5+D5gb MjM8AW7EEA6KXj2PqrPv/H/brorW9/Ugcc8KweCjEdJAKOJV/Bl6sP5ydSZT6pmj A0IFIkbdxKLY9JC3BbmVHuiAFrsL1u2EX5arUC3WNAWeWlVEmAL92cSlAka4BBxy P/wh8xN0b4hsgA602Y4Btkv2fBHLQI9NMxW3AsujP3/S78mSxwKQZz4lYAMCowu8 NL/3toaFhrUsdHsH301jNAnxEEOodMVGmgjg/ZSdvWeHwdsE2J8Q9AJqiFDswjU5 q2kZuKmuJ6EXcGDlhelUuUpfHO34qS3/dyTydcqFrYB6eynZ8nV6S1SHaSlDEM10 b95+EpfIENtYdgAqJxwfbqpibpSEIW7cxCAopF0sSbQ2qv8rwRrcIah7KeARCrc0 e+HDcyLhYkrWrlK28vVmIxkEiQ/nmkTu9dOfoVJgXxcVl9AkiHGjo7QICOZHqfRB TOupk9UUHMmdfZC5vpj9rd+VSXJJEF19ZbGF1QsFSMuxjKTb9jAy7Dk6U/9/xK9Q +mH6QHhKzNKb8GsiowZJq3bF2mEYqmh/BPyQ06gfDLM4yvlTb+k4R6brFzm7tkWG 49hREmHK9w/wZXnH0lMCqMHRY/YqQF5bR3ujq7pB0WHLvbvDoSvyWvGQ9cVrRA24 ASb47sR77R1LlZntoSyy =b7HG -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reusable payment codes
On Fri, Apr 24, 2015 at 8:00 PM, Justus Ranvier justus.ranv...@monetas.net wrote: 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. 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. 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.) Alice selects the first exposed public key of the first input of the transaction So this creates strong binding that we would really strongly like to avoid in the network; basically what this says is that You can only pay to person X if you use scheme Y for your own Bitcoins-- who says any of your inputs have a ECDH pubkey at all? Of if they do, who says its one that you have access to the private key for for use in this scheme (e.g. it could be in a HSM that only signs according to a policy). We should avoid creating txout features that restrict what kind of scriptPubkey the sender can use, or otherwise we'll never be able to deploy new signature features. (We can see how long P2SH took to gain adoption because some wallets refused to implement sending to it, even though doing so was trivial). 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) Also, SPV wallets do not need to have access to the public keys being spent by a particular transaction they learn about; providing that access is fundamentally expensive and pushes things back towards centralization. in uncompressed DER format This is fundamentally more expensive to compute; please don't specify uncompressed. This appears incompatible with multisignature; which is unfortunate. I do very much like the fact that this scheme establishes a shared chain once and then doesn't need to reestablish; this was one of the improvements I wanted for the stealth address. 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? -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
