Re: [Bitcoin-development] Stealth Payments - Sample Code / Proof of Concept
Cool! On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman jer...@taplink.co wrote: I spent 1BTC on TestNet to a stealth address... TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c ... but can you redeem it? Code which generated this transaction is here: https://gist.github.com/jspilman/8396495 That's rather interesting code. Is this using a private C# bitcoin implementation? I wonder if the 0BTC OP_RETURN transactions should be hidden from the Transaction List? Yes, of course. The transaction list should just say something like Payment received from Jeremy, 0.1 BTC Maybe the simple way to punt on this is to just show 'Merchant' in the address column if it is available and an address is not. I am surprised it's not already the case! Though merchant is perhaps a bit biased as a name, internally it perhaps should just be called Recipient. There's no requirement for you to be a merchant to create payment protocol requests. I can probably make the necessary changes to IsMine, but I don't know where we should keep 'd2'/'Q2' unencrypted so it's available for doing the necessary tests, but has no chance of ever be used as a stand-alone private key? The wallet format would need extending. I'd feel a lot more comfortable if the protocol was reviewed by a professional cryptographer though. I think think Gregory already brought up an issue to do with people able to detect such payments by testing if decrypted values are points on the curve, or something like that. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
I was thinking that people could upload a payment protocol file somewhere once (like to their personal web page, or shared via dropbox or google drive or some custom new pastebin style service), and then just encode a regular bitcoin URI into the qrcode on the billboard. That does require trusting the third party not to later tamper with the payment request, though. (I'm assuming that a signed payment request is not always going to be all that useful in the case of private individuals, even assuming the payee is willing to sign up for one.) Likewise, I could attach a payment request to an email and send it to you, and now you can pay me whenever you want forever. That certainly sounds like a plausible use case. You do still have the problem that e-mail is an insecure channel, but it's no worse than exchanging Bitcoin addreses over e-mail as things stand at the moment. roy -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Payments - Sample Code / Proof of Concept
On Mon, 13 Jan 2014 03:18:28 -0800, Mike Hearn m...@plan99.net wrote:Cool!On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman jer...@taplink.co wrote: I spent 1BTC on TestNet to a stealth address... TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c... but can you redeem it?But of course!Every time the test runs it makes a new ephemeral key, so I wrote a separate test with hard-coded values from the block chain (as it would be in real-life) to create a redeeming Tx. I've added the RedeemStealth code to the Gist.It sent successfully using sendrawtransaction, TxID: ed92364d2b6f6528dea32dbf6c4d5d6291b601aff1ddb4eeb124d003c7c7ff07I'm self mining since no one else seems to be on TestNet this time of night... going to catch some sleep, hopefully by the time I wake up it'll be on the chain. Code which generated this transaction is here: https://gist.github.com/jspilman/8396495That's rather interesting code. Is this using a private C# bitcoin implementation?Indeed it is. One day I may publish the libraries, but they aren't doing anything particularly special under the hood, just the standard Bitcoin/EC/BIP32 stuff and using OpenSSL under the hood instead of the more typical BouncyCastle.I just tried to keep things extremely concise in the APIs. Hopefully all the function calls are obvious what they are doing. Since there's no actual wallet behind it, the code to setup the inputs is a bit annoying, but actually building and signing transactions is super clean.I wonder if the 0BTC OP_RETURN transactions should be hidden from the Transaction List?Yes, of course. The transaction list should just say something like "Payment received from Jeremy, 0.1 BTC"In this case I'm just looking at the payee wallet, but yes, "Payment set to Jeremy" should be possible, with the name coming from the CN. Maybe the simple way to punt on this is to just show 'Merchant' in the address column if it is available and an address is not.I am surprised it's not already the case! Though "merchant" is perhaps a bit biased as a name, internally it perhaps should just be called "Recipient". There's no requirement for you to be a merchant to create payment protocol requests.Yeah, right now for PaymentProtocol fulfilled payments, on the payer's Transaction List, it shows the address in the 'Address' column, but if you right-click and look at 'Transaction details' you will see something like: Status: 42 confirmations Date: 1/12/2014 21:07 To: mrhz5ZgSF3C1BSdyCKt3gEdhKoRL5BNfJV Debit: -0.10 BTC Net amount: -0.10 BTC Transaction ID: 93c50347e35062a3501fcea15d1a22ace8d1b059affb9913fc9e7df4e7d6a00b-000 Merchant: www.bitcoincore.orgI agree 'Merchant' might not be the best name, especially since when you're making the payment the field is labeledsimply 'Pay To'.But I think we agree, why show 'mrhz5ZgSF3C1BSdyCKt3gEdhKoRL5BNfJV' in the transaction list instead of just"Paid To: www.bitcoincore.org" and then perhaps the Memo field could be stuck under 'Transaction details', instead of losing that important bit of info. I can probably make the necessary changes to IsMine, but I don't know where we should keep 'd2'/'Q2' unencrypted so it's available for doing the necessary tests, but has no chance of ever be used as a stand-alone private key?The wallet format would need extending.I'd feel a lot more comfortable if the protocol was reviewed by a professional cryptographer though. I think think Gregory already brought up an issue to do with people able to detect such payments by testing if decrypted values are points on the curve, or something like that. Not sure I follow that, will look forward to hearing more about it.The only risk I know of is that there are checks in theory that you would do on Q1/Q2, but since the payee is the one generating Q1/Q2 they would literally be attacking themselves. I referenced two papers in a prior email specifically on reusing ephemeral keys in ECDH, and the validation you need to do on Q1/Q2 when re-using an ephemeral key to send two messages to two different pubKeys. I think the idea of checking the pubKeys when re-using ephemeral keys is more when the pubKeys are under the attackers control. But the validation is not complicated, and I'll see if I can add it tomorrow.It would be good to fully understand how a possible small-group attack would work... This is a bit of guess-work on my part: If a payee managed to foot-shoot themselves with a bad Q2 pubKey, then gives out d2/Q2 to a scanning service run by Mallory... Mallory has d2/Q2, given P from a transaction, he calculates S2 (as usual): byte[] S2 = EC.DH(d2, P); But with the small sub-group attack with Q2 he can learn 'e' (the ephemeral private key) used: byte[] S2 = EC.DH(e, Q2); and from that he can calculate S1 directly, when he should only know S2. byte[] S1 = EC.DH(e, Q1); So does that mean Mallory can find 'd1'? It looks like you would need another small sub-group attack on P, the ephemeral public key, so another key the attacker doesn't
Re: [Bitcoin-development] Stealth Addresses
Likewise, I could attach a payment request to an email and send it to you, and now you can pay me whenever you want forever. That certainly sounds like a plausible use case. You do still have the problem that e-mail is an insecure channel, but it's no worse than exchanging Bitcoin addreses over e-mail as things stand at the moment. On further reflection, I'm not sure I understand this use case of the payment protocol. Since a PaymentRequest currently contains the Outputs that specify the addresses to send to, reusing a PaymentRequest like this without using stealth addresses implies address reuse. (Granted there are alternative solutions to stealth addresses, such as a BIP32-style derivation.) roy -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On further reflection, I'm not sure I understand this use case of the payment protocol. Since a PaymentRequest currently contains the Outputs that specify the addresses to send to, reusing a PaymentRequest like this without using stealth addresses implies address reuse. Yes indeed .. which is why we're talking about extending the protocol (in a future version! the first version isn't even out yet!). -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner etothe...@gmail.com wrote: Then when someone wants to pay you, you simply give them the multiplier and root key (they already have the root key, but should verify). [...] What advantages does stealth addresses have over this scheme? You could extend it using some kind of deterministic sub-branching and/or ECDH to create multiple payment addresses without querying the payee. The stealth address stuff is the ECDH to create multiple payment addresses without querying the payee. Uh while I'm responding again, what I'd discussed with Peter Todd in IRC used two EC points in the stealth address. One for the payment and one for the ECDH. The reason to use two is that it makes delegating detection possible and so you don't have to have you spending keys online to even detect these payments. Why'd that get dropped? I don't think this is a good idea if you have to constantly keep your spending key(s) online even to detect payments, even with the limited use-cases envisioned. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote: Signing a payment request for an individual is easy, anyway, depending on the kind of ID you want. If you want to sign with an email address, just go here with a browser like Chrome/Safari/IE that uses the system keystore: http://www.comodo.com/home/email-security/free-email-certificate.php Ok, cool, I wasn't aware of such services, and I can certainly see they could be useful. But it's not that great for the business card scenario. As far as I can see, using it in that scenario would have to rely on the payer scanning the QR code on the business card, and then check that the email address displayed by their wallet matched the email address printed on the business card. roy -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Mon, Jan 13, 2014 at 12:10:56PM -0800, Gregory Maxwell wrote: Uh while I'm responding again, what I'd discussed with Peter Todd in IRC used two EC points in the stealth address. One for the payment and one for the ECDH. The reason to use two is that it makes delegating detection possible and so you don't have to have you spending keys online to even detect these payments. Why'd that get dropped? I mentioned it again in another email; I just forgot to include it in my final write-up. -- 'peter'[:-1]@petertodd.org 00023d5a8bbe131414328a6c50a2741933ba03775afd3c3db395 signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On 01/13/2014 04:02 PM, Roy Badami wrote: It's not public. When I say please pay me I also say use this multiplier. Sending a please pay me message is really great for business transactions. But I think the use case that Peter Todd mentions is actually *the* most important currently under-addresesd use case: With stealth addresses the user experience can be as simple as you telling me on the phone hey! send me that 0.234 BTC you owe me!, me clicking on Send to Alan Reiner (verified by PGP) (perhaps again on my off-line second factor device for a multi-sig wallet) and tellling you OK, sent. Lots of work is being done on handling consumer-to-merchant transactions. BIP 70 does a good job of tackling the online purchase case, and the work that Andreas Schildbach is doing with Bluetooth and NFC will improve the options for a payer in a physical PoS transaction who might not have Internet connectivity on their smartphone. But relatively little work (that I know of) is being done on non-transactional personal payments - that is, being able to pay money to friends and other people that you have a face-to-face relationship with. What I want... no need... is to be able to open my wallet, select a friend from my address book, and transfer the $10 I owe them from the bar last night. I don't care - within reason - what process is involved in getting my friend set up in my address book. That may well requires two way communication (e.g. over NFC). But once it's set up, I should be able to just select the payee from the address book and send them some funds. Anything else is just too complciated. I don't know if stealth addresses are the best solution to address this use case, but AFAIK the only current solution to this use case is to store a long-lived Bitcoin address in the addresss book. roy Fair enough. I haven't spent much time thinking about that use case. Though, I question the feasibility of anything that requires O(N) EC multiply operations/sec, where N is the total volume of transactions moving over the network. But I guess if the prefix is big enough, the scanning operations will remain feasible forever. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Mon, Jan 13, 2014 at 04:15:01PM -0500, Alan Reiner wrote: I don't know if stealth addresses are the best solution to address this use case, but AFAIK the only current solution to this use case is to store a long-lived Bitcoin address in the addresss book. roy Fair enough. I haven't spent much time thinking about that use case. Though, I question the feasibility of anything that requires O(N) EC multiply operations/sec, where N is the total volume of transactions moving over the network. But I guess if the prefix is big enough, the scanning operations will remain feasible forever. Well that's the thing: the cost to find all stealth-address-using payments to you isn't O(n) transaction volume, it's O(n) anonymity set size. I think we can make a pretty good argument that the anonymity set people need is mostly fixed in size and has nothing to do with overall tx volume, so really we've got O(1) scaling. There is a catch however: if you need the prefix to be against H(scriptPubKey) rather than scriptPubKey directly the sender needs to grind the OP_RETURN output at 2^len(prefix) cost. Fortunately that grinding can be done with hash operations rather than ECC - even if we needed 32-bit prefixes eventually computing 32-bit hash collisions is plausible, and more reasonable 8-bit is quite doable now. -- 'peter'[:-1]@petertodd.org 00013f56c73dbb82447ba01e303648109b2e7ea0adf6ca53a7ff signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
Thanks for the explanation. On 01/13/2014 06:56 PM, Pieter Wuille wrote: As for you proposal, just be aware I'd like to use the payment protocol for face to face payments as well. That meant payment request via NFC or QR, payment message and payment confirmations via Bluetooth. I think it can be done by putting a Bluetooth mac address into the payment_url. I'm aware. What issues do you see? Looks good so far. Just wanted to keep you aware (-: -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
