jgarzik





Offline



Activity: 1596

Merit: 1007







LegendaryActivity: 1596Merit: 1007 [PATCH] bitcoin scratch-off cards March 17, 2011, 09:05:36 AM

Last edit: March 23, 2011, 09:07:42 PM by jgarzik #1



http://yyz.us/bitcoin/patch.bitcoin-scratch-card

or git://github.com/jgarzik/bitcoin.git#scratch-card



To create a scratch-off card for 0.82 BTC from the 'master' account via JSON-RPC:



Code: $ bitcoind sendscratchoff master 0.82 '{ "bits" : 64, "salt" : "myawesome.com" }' 1 "my awesome scratch-off"

{

"txid" : "4a16969aa4764dd7507fc1de7f0baa4850a246de90c45e59a3207f9a26b5036f",

"password" : "719d17195638f937"

}



And presumably you will have a fancy print-out or display saying



Redeem this card for 0.82 bitcoins!

card# 4a16 969a

presented by: myawesome.com

password 719d 1719 5638 f937



Some time later, the holder of this card may redeem their 0.82 BTC with another new RPC 'scratchoff':



Code: $ bitcoind scratchoff 4a16969a 719d17195638f937 "myawesome.com"

994dd0219f6dea648a6d5f8d33850114a2a0787e136a36e8b24ccafcd6ff0e59

^^^ transaction that "claims" the scratch-off card





How it works

--------------------------------------------------------------------

After re-reading



Our EC private keys are 256 bits

Generate 64-1024 random bits (def. 64) -- this is your scratch-off password

Perform a great many rounds of hashing the password, and a user-supplied salt string (default "bitcoin"), to produce 256 bits of data

Create EC keypair with the resultant 256 bits of post-hash data

Create transaction, sending n.nn BTC to the hash of the EC public key

Return 32 bits of transaction hash ("id") and scratch-off password ("password") via JSON-RPC

To redeem a scratch-off,



Retrieve transaction by looking up N bits of the transaction hash ("txid")

Build raw 256-bit private key, through many rounds of hashing the password ("password") and salt ("salt")

Create EC keypair from raw private key

Verify transaction output's pubkey hash matches EC pubkey hash

Add EC keypair and scratch-off TX to local wallet

Create transaction that sends bitcoins from scratch-off TX to a new key in your own wallet, thereby "claiming" the card.

You may now spend those bitcoins, once your claim is confirmed (requires at least 1 confirmation by default)

Because this is an entirely normal transaction, willingly relayed by all existing clients, no outside observer will know that this spend is a scratch-off card, rather than a regular spend to a regular bitcoin address.



Variations:



(1) Use decimal digits instead of hexidecimal, for id and password. More consumer friendly. Requires a small amount of brute forcing, if one limits the password to 16 digits, to recover the lost bits.



(2) If you have a full block chain, and EC pub/private keys, the transaction hash ("txid") is optional. One could simply scan the block chain for an unspent transaction to the given bitcoin address (derived from the password).



Credit for all bugs goes to me. Credit for the ideas goes to bytecoin, art, theymos and the authors of RFC 2898.



EDIT: Updated to reflect changes through March 23.

This patch adds the "sendscratchoff" RPC call, which creates transactions that are an electronic attempt at scratch-off cards:or git://github.com/jgarzik/bitcoin.git#scratch-cardTo create a scratch-off card for 0.82 BTC from the 'master' account via JSON-RPC:And presumably you will have a fancy print-out or display sayingSome time later, the holder of this card may redeem their 0.82 BTC with another new RPC 'scratchoff':How it works--------------------------------------------------------------------After re-reading this old thread , a discussion on IRC led ArtForz to note that ByteCoin suggested a way to create bitcoin scratch-off cards within a standard transaction. Unless I've totally bollock's up the works, which is entirely possible, here's how it works:To redeem a scratch-off,Because this is an entirely normal transaction, willingly relayed by all existing clients, no outside observer will know that this spend is a scratch-off card, rather than a regular spend to a regular bitcoin address.Variations:(1) Use decimal digits instead of hexidecimal, for id and password. More consumer friendly. Requires a small amount of brute forcing, if one limits the password to 16 digits, to recover the lost bits.(2) If you have a full block chain, and EC pub/private keys, the transaction hash ("txid") is optional. One could simply scan the block chain for an unspent transaction to the given bitcoin address (derived from the password).Credit for all bugs goes to me. Credit for the ideas goes to bytecoin, art, theymos and the authors of RFC 2898.: Updated to reflect changes through March 23. Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.

Visit bloq.com / metronome.io

Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj

Anonymous Guest



Re: [PATCH] bitcoin scratch-off cards March 17, 2011, 09:39:14 AM #2



Someone sends you a card or you purchase one.



Using a touch screen you simply swipe your finger like you are rubbing a physical scratch card .





Im thinking this could be the most awesome iphone or android app.Someone sends you a card or you purchase one.Using a touch screen you simply swipe your finger like you are rubbing a physical scratch card .

mndrix

VIP

Sr. Member



Offline



Activity: 447

Merit: 255







Michael HendricksVIPSr. MemberActivity: 447Merit: 255 Re: [PATCH] bitcoin scratch-off cards March 17, 2011, 02:25:29 PM #4 This is excellent and very clever! I'm not competent to speak to the implementation details, but I'd love to use this feature at CoinPal. I could eliminate purchase limits for customers choosing scratch-off card delivery in the mail.

ByteCoin





Offline



Activity: 416

Merit: 257







Sr. MemberActivity: 416Merit: 257 Re: [PATCH] bitcoin scratch-off cards March 17, 2011, 03:54:59 PM #5 Quote from: theymos on March 17, 2011, 12:38:26 PM How long does it take to break an ECDSA key with only 64 bits of unknown key?



As very nearly every 256bit number is a valid secp256k1 private key, there's no reason to imagine (off the top of my head) why there should be any attack faster than brute force.



Note to self: I have thought of a possible implementation detail that would need to be taken care of in order to stop a birthday paradox attack. Details when I have time.



ByteCoin As very nearly every 256bit number is a valid secp256k1 private key, there's no reason to imagine (off the top of my head) why there should be any attack faster than brute force.Note to self: I have thought of a possible implementation detail that would need to be taken care of in order to stop a birthday paradox attack. Details when I have time.ByteCoin

theymos

Legendary



Offline



Activity: 3878

Merit: 7917







AdministratorLegendaryActivity: 3878Merit: 7917 Re: [PATCH] bitcoin scratch-off cards March 17, 2011, 06:33:02 PM #6 When I mentioned the idea of exposing part the private key to the people on ##crypto on Freenode (at the time when I wrote my scratch-off thread), they were very opposed to the idea. They seemed to think that security would be significantly decreased.



Probably the cost of performing any attack would be higher than the actual value of the scratch-off transaction, though. 1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD

Hal

Sr. Member





Offline



Activity: 314

Merit: 1014









VIPSr. MemberActivity: 314Merit: 1014 Re: [PATCH] bitcoin scratch-off cards March 17, 2011, 07:21:02 PM #7 It's not safe to have only 64 bits of the private key be unknown. This can be broken in 2^32 work using such algorithms as baby step giant step, Pollard rho, or the kangaroo. Hal Finney

jgarzik





Offline



Activity: 1596

Merit: 1007







LegendaryActivity: 1596Merit: 1007 Re: [PATCH] bitcoin scratch-off cards March 17, 2011, 07:31:59 PM #8 Quote from: theymos on March 17, 2011, 06:33:02 PM When I mentioned the idea of exposing part the private key to the people on ##crypto on Freenode (at the time when I wrote my scratch-off thread), they were very opposed to the idea. They seemed to think that security would be significantly decreased.



Would be interesting to have more specific criticisms, now that code's out there. The main question, as ByteCoin indicated, is whether or not there is an attack that is faster than brute force, if you know a portion of the private key.



As the Variations section hints, the implementation presented was the most simple to implement, not necessarily the most consumer friendly or the most secure. When deploying this into production, should it make it into the bitcoin client, I would do a couple things, such as

require some level of brute forcing for all redemptions (have bits neither in well-known private key subset, or the password)

ship 1,000 well-known 192-bit private key subsets

Each valid redemption would therefore require some amount of brute forcing, while an attacker has a lot of work to do comparatively -- they have to first recognize a scratch-off from a normal spend, in the block chain. Then they would have to find the remaining ~64+ bits of private key, having only the public key (or a hash thereof) as a starting point.



I readily admit I am no cryptographer or math genius, though! Hopefully the future will bring more substantive criticisms from #crypto than "exposing part of private key leaves me vaguely unsettled"



Would be interesting to have more specific criticisms, now that code's out there. The main question, as ByteCoin indicated, is whether or not there is an attack that is faster than brute force, if you know a portion of the private key.As the Variations section hints, the implementation presented was the most simple to implement, not necessarily the most consumer friendly or the most secure. When deploying this into production, should it make it into the bitcoin client, I would do a couple things, such asEach valid redemption would therefore require some amount of brute forcing, while an attacker has aof work to do comparatively -- they have to, in the block chain. Then they would have to find the remaining ~64+ bits of private key, having only the public key (or a hash thereof) as a starting point.I readily admit I am no cryptographer or math genius, though! Hopefully the future will bring more substantive criticisms from #crypto than "exposing part of private key leaves me vaguely unsettled" Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.

Visit bloq.com / metronome.io

Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj