16 ms·

A peek under Bitcoin’s hood: Writing a client that can create a transaction

241 points by samlewis 9y ago

hdhzy 9y ago
Very cool. This could be used to implement offline wallet with minimal amount of third party code. One issue I'd like to point is I wish the author used proper random generated private key. Examples on the internet have a nasty habits of being copy pasted and reused verbatim :(
- jerguismi 9y ago
  Not using cryptographically safe random key is very stupid, even though it is only an example. It should be very trivial to fix this example. I think in python the right way is to use the os.urandom() function.
- samlewis 9y ago
  My intention in using "hand crafted"/memorable private keys was just to make the article and what I was doing easier to follow. I don't think there's any harm in people copying and pasting examples, it only becomes an issue if they start depositing money to either of the addresses that I listed the private keys for. I hope that's an obvious enough mistake not to make! Thanks for the feedback anyway, I'll keep an eye on those addresses and if they start getting mysterious deposits change the article to include more cryptographically secure keys.
mason55 9y ago
Article says > This is also why address reuse in Bitcoin is encouraged as to sign a transaction you need to reveal your public key. If you don't reuse an address after sending a transaction from the address, you don't need worry about the private key of that address being exposed. Shouldn't that say "address reuse in Bitcoin is discouraged"? Otherwise I don't think I understand what he's trying to say.
- deleted 9y ago
  [deleted]
- coopc 9y ago
  Address reuse is most certainly discouraged from a security standpoint! I expect that you are correct as to the article's intended meaning.
- narrator 9y ago
  Address reuse only becomes a problem in the theoretical case that someone can determine the private key from a signature. This would only happen if there was some sort of breakthrough in cryptoanalysis of elliptic curve cryptography, which while theoretically possible, is unlikely.
  - Obi_Juan_Kenobi 9y ago
    The idea is that you don't want to be secure now, but also in the future. The ECC Bitcoin uses is vulnerable to Shor's algorithm, and thus quantum computation. Quantum computing at that scale is a fair ways off, most likely, but on a timescale of a couple decades or more, a successful attack seems quite reasonable. Bitcoin can soft-fork, allowing address generation with a different algorithm. It's not any sort of existential threat to Bitcoin. But it does require that you move your coins to a new address if you reuse an address, else you are vulnerable.
  - 45h34jh53k4j 9y ago
    or you reuse the nonce in ECDSA. This burned sony, and burned people that had faulty wallet code that submitted transactions with the duplicate nonces. If you only published, and signed a transaction once, you would be immune to fail by ECDSA nonce reuse. Its good to rotate the publickey/address per transaction in bitcoin
  - julian_1 9y ago
    Not to mention, that such a discovery would be significant enough - that a protocol upgrade and fork would be inevitable, in order to protect addresses retroactively.
afeezaziz 9y ago
Hi Sam, If you're reading the comments, can you do this treatment but for Ethereum and the smart contracts built on top of it? I find that your article gives a good explanation especially for beginner to understand from the code perspective.
- ecesena 9y ago
  FWIW, I was looking at eth code in the weekend and it's pretty accessible (I was looking at go -- I've read that eth python should be even more readable). The address part is very similar, even simpler, than bitcoin. It's the same elliptic curve, same way to build private/public keys. For the address, it uses a different hash function, Keccak256, and then it's just serialized in hex. Code here [1]. Pointers to key generation [2, 3]. [1] https://github.com/ethereum/go-ethereum/blob/release/1.6/crypto/crypto.go#L181 https://github.com/ethereum/go-ethereum/blob/release/1.6/cry... [2] https://github.com/ethereum/go-ethereum/blob/release/1.6/accounts/keystore/key.go#L169 https://github.com/ethereum/go-ethereum/blob/release/1.6/acc... [3] https://github.com/ethereum/go-ethereum/blob/release/1.6/accounts/keystore/key.go#L138 https://github.com/ethereum/go-ethereum/blob/release/1.6/acc...
  - tuxxy 9y ago
    Keccak256? Isn't that just SHA3 with a digest of 256 bits?
    - ecesena 9y ago
      I'm unsure. I think this came before sha3 was defined so some parameters may have changed. But the core is essentially that.
      - tylersmith 9y ago
        There are minor padding differences but that's it.
    - ryan-c 9y ago
      No, it's slightly different from SHA3-256. There was a tweak for standardization.
nurettin 9y ago
>> 0xFACEBEEF and sent it 0.0005 BTC.. 1 month later and someone had stolen my 0.0005 BTC! I guess people must occasionally trawl through addresses with simple/common private keys. This made it worth reading the article. Such cyberpunk!
- thefalcon 9y ago
  For fun[1], you can occasionally trawl through addresses with any private key! http://directory.io/ http://directory.io/ [1] For various definitions of "fun."
  - 293984j29384 9y ago
    Their FAQ (unlisted on the main page) is interesting as well.. https://directory.io/faq https://directory.io/faq
philfrasty 9y ago
Can someone explain why bitcoin adresses can be created (offline) without blockchain-validation for duplicates? Even if the chances are very small I mean...like....gone is gone...no bank to call for a false transaction.
- wildbunny 9y ago
  https://bitcoin.stackexchange.com/questions/22/is-it-possible-to-brute-force-bitcoin-address-creation-in-order-to-steal-money https://bitcoin.stackexchange.com/questions/22/is-it-possibl...
  - philfrasty 9y ago
    doesn't answer my question. (accepted answer includes) „...It may be "theoretically" possible...“
- adrianmacneil 9y ago
  Bitcoin addresses are basically a public key, so you can generate them offline the same way you can generate pgp keys, openssl keys, SSH keys you use to access GitHub etc. The chances of a collision are so astronomically low that our sun will probably run out of fuel and explode before two identical keys are generated.
  - philfrasty 9y ago
    With the comfort of a public blockchain at hand why not eliminate this case at address-creation time?
    - adrianmacneil 9y ago
      You could, but it's simply not necessary. I have not verified the numbers, but I think this answer gives a better idea of the scale we are talking about: https://bitcoin.stackexchange.com/a/3205 https://bitcoin.stackexchange.com/a/3205
    - 9y ago
donpdonp 9y ago
This is an excellent writeup! If any readers are looking for an already-written and tested bitcoin client library and can use javascript, https://bitcoinjs.org/ https://bitcoinjs.org/ is great. I wrapped a simple cli tool around the library to make the 'coindust' npm package to do simple operations with bitcoin addresses and public bitcoin APIs.
ryan-c 9y ago
I am actually really surprised it took a month for someone to swipe the BTC he sent to an address with a private key of 0xfacebeef. That could be found via an incremental search in under an hour of CPU search time on one computer. I note that compressed public keys are not being used in these examples - it's highly recommended to use them, since they reduce transaction size and cost. Regarding weak keys - there have been a lot of weak key generation techniques in bitcoin where hiding the public key won't do you any good.
- lordnacho 9y ago
  Just a warning for people, I was playing around with BTC the other day and not generating random entropy from urandom, just putting in a short string. I found my BTC was stolen immediately when I did this. It wasn't a lot of coins, since I was just testing, but it certainly cost me some debugging time as I wondered how the extra transaction had occurred. Basically, someone out there has already generated the keys corresponding to short strings and is keeping an eye on any transactions on them. Maybe more than one group, who knows?
  - tylersmith 9y ago
    There are many of us with bots sweeping weak keys. Some of us give the coins back to a safe address, some people just keep it. It's like finding money on the sidewalk.
    - jacquesm 9y ago
      No, it's like picking money off the sidewalk when someone drops their coins and then running away.
      - tylersmith 9y ago
        It depends on if they "run away" and keep it, or if they return it to the proper owner in a secure manner.
    - baudehlo 9y ago
deleted 9y ago
[deleted]
ryan-c 9y ago
Looks like there was bitcoin left in the address he published the private key for until about 30 minutes ago. I hope that was a deliberate giveaway. https://blockchain.info/tx/2685ff794de17cebdf94eb0f111e8b8c03529a9ae628909cef4090663b54e565 https://blockchain.info/tx/2685ff794de17cebdf94eb0f111e8b8c0...
- jameskegel 9y ago
  As of the time of publishing, roughly ~8.58 USD.
- samlewis 9y ago
  I did deliberately leave that there in the hope someone might take it using what they'd learnt from the article. there's a short note about this in the conclusion to the article. From the "non whole" fee amount it looks as though someone might have just used some sort of wallet software to take it though, which is a shame.
sprt 9y ago
Wrt transactions, I don't understand why you need to send yourself the unspent BTCs. Why does it make things significantly easier?
- iso-8859-1 9y ago
  Because the miner almost always expects a fee, so why not just infer how high it is and you don't need to spend block bytes on it?
  - sprt 9y ago
    Ok, but the unspent output takes space as well. I think you could just replace it with the fee. Not sure if I'm missing something or if it was just an arbitrary design decision.
    - samlewis 9y ago
      It has to do with the way transactions and the blockchain ledger works, reread the transaction part of the article and it might make more sense. Basically, transaction outputs can either be spent or unspent, you can't half spend an output (or perhaps more accurately, you can't spend a previous output twice).
      - sprt 9y ago
        Yes I understand that's how it works, but I don't get why it's important. Surely you could double spend an output as long as you don't exceed its value; and that looks easily verifiable.
        samlewis 9y ago
        Ah, my bad. Sorry if I was being condescending in my previous reply then. I suspect it was a design decision, yeah. If outputs could be spent multiple times then you'd need to traverse the chain of outputs backwards to see how much an output has left in it. Bitcoin's implementation is less complex and more elegant, imo.

241 points by samlewis 9y ago

Very cool. This could be used to implement offline wallet with minimal amount of third party code. One issue I'd like to point is I wish the author used proper random generated private key. Examples on the internet have a nasty habits of being copy pasted and reused verbatim :(

jerguismi 9y ago
Not using cryptographically safe random key is very stupid, even though it is only an example. It should be very trivial to fix this example. I think in python the right way is to use the os.urandom() function.
samlewis 9y ago
My intention in using "hand crafted"/memorable private keys was just to make the article and what I was doing easier to follow. I don't think there's any harm in people copying and pasting examples, it only becomes an issue if they start depositing money to either of the addresses that I listed the private keys for. I hope that's an obvious enough mistake not to make! Thanks for the feedback anyway, I'll keep an eye on those addresses and if they start getting mysterious deposits change the article to include more cryptographically secure keys.

mason55 9y ago

Article says > This is also why address reuse in Bitcoin is encouraged as to sign a transaction you need to reveal your public key. If you don't reuse an address after sending a transaction from the address, you don't need worry about the private key of that address being exposed. Shouldn't that say "address reuse in Bitcoin is discouraged"? Otherwise I don't think I understand what he's trying to say.

deleted 9y ago
[deleted]
coopc 9y ago
Address reuse is most certainly discouraged from a security standpoint! I expect that you are correct as to the article's intended meaning.
narrator 9y ago
Address reuse only becomes a problem in the theoretical case that someone can determine the private key from a signature. This would only happen if there was some sort of breakthrough in cryptoanalysis of elliptic curve cryptography, which while theoretically possible, is unlikely.
- Obi_Juan_Kenobi 9y ago
  The idea is that you don't want to be secure now, but also in the future. The ECC Bitcoin uses is vulnerable to Shor's algorithm, and thus quantum computation. Quantum computing at that scale is a fair ways off, most likely, but on a timescale of a couple decades or more, a successful attack seems quite reasonable. Bitcoin can soft-fork, allowing address generation with a different algorithm. It's not any sort of existential threat to Bitcoin. But it does require that you move your coins to a new address if you reuse an address, else you are vulnerable.
- 45h34jh53k4j 9y ago
  or you reuse the nonce in ECDSA. This burned sony, and burned people that had faulty wallet code that submitted transactions with the duplicate nonces. If you only published, and signed a transaction once, you would be immune to fail by ECDSA nonce reuse. Its good to rotate the publickey/address per transaction in bitcoin
- julian_1 9y ago
  Not to mention, that such a discovery would be significant enough - that a protocol upgrade and fork would be inevitable, in order to protect addresses retroactively.

afeezaziz 9y ago

Hi Sam, If you're reading the comments, can you do this treatment but for Ethereum and the smart contracts built on top of it? I find that your article gives a good explanation especially for beginner to understand from the code perspective.

ecesena 9y ago
FWIW, I was looking at eth code in the weekend and it's pretty accessible (I was looking at go -- I've read that eth python should be even more readable). The address part is very similar, even simpler, than bitcoin. It's the same elliptic curve, same way to build private/public keys. For the address, it uses a different hash function, Keccak256, and then it's just serialized in hex. Code here [1]. Pointers to key generation [2, 3]. [1] https://github.com/ethereum/go-ethereum/blob/release/1.6/crypto/crypto.go#L181 https://github.com/ethereum/go-ethereum/blob/release/1.6/cry... [2] https://github.com/ethereum/go-ethereum/blob/release/1.6/accounts/keystore/key.go#L169 https://github.com/ethereum/go-ethereum/blob/release/1.6/acc... [3] https://github.com/ethereum/go-ethereum/blob/release/1.6/accounts/keystore/key.go#L138 https://github.com/ethereum/go-ethereum/blob/release/1.6/acc...
- tuxxy 9y ago
  Keccak256? Isn't that just SHA3 with a digest of 256 bits?
  - ecesena 9y ago
    I'm unsure. I think this came before sha3 was defined so some parameters may have changed. But the core is essentially that.
    - tylersmith 9y ago
      There are minor padding differences but that's it.
  - ryan-c 9y ago
    No, it's slightly different from SHA3-256. There was a tweak for standardization.

nurettin 9y ago

>> 0xFACEBEEF and sent it 0.0005 BTC.. 1 month later and someone had stolen my 0.0005 BTC! I guess people must occasionally trawl through addresses with simple/common private keys. This made it worth reading the article. Such cyberpunk!

thefalcon 9y ago
For fun[1], you can occasionally trawl through addresses with any private key! http://directory.io/ http://directory.io/ [1] For various definitions of "fun."
- 293984j29384 9y ago
  Their FAQ (unlisted on the main page) is interesting as well.. https://directory.io/faq https://directory.io/faq

philfrasty 9y ago

Can someone explain why bitcoin adresses can be created (offline) without blockchain-validation for duplicates? Even if the chances are very small I mean...like....gone is gone...no bank to call for a false transaction.

wildbunny 9y ago
https://bitcoin.stackexchange.com/questions/22/is-it-possible-to-brute-force-bitcoin-address-creation-in-order-to-steal-money https://bitcoin.stackexchange.com/questions/22/is-it-possibl...
- philfrasty 9y ago
  doesn't answer my question. (accepted answer includes) „...It may be "theoretically" possible...“
adrianmacneil 9y ago
Bitcoin addresses are basically a public key, so you can generate them offline the same way you can generate pgp keys, openssl keys, SSH keys you use to access GitHub etc. The chances of a collision are so astronomically low that our sun will probably run out of fuel and explode before two identical keys are generated.
- philfrasty 9y ago
  With the comfort of a public blockchain at hand why not eliminate this case at address-creation time?
  - adrianmacneil 9y ago
    You could, but it's simply not necessary. I have not verified the numbers, but I think this answer gives a better idea of the scale we are talking about: https://bitcoin.stackexchange.com/a/3205 https://bitcoin.stackexchange.com/a/3205
  - 9y ago

donpdonp 9y ago

This is an excellent writeup! If any readers are looking for an already-written and tested bitcoin client library and can use javascript, https://bitcoinjs.org/ https://bitcoinjs.org/ is great. I wrapped a simple cli tool around the library to make the 'coindust' npm package to do simple operations with bitcoin addresses and public bitcoin APIs.

ryan-c 9y ago

I am actually really surprised it took a month for someone to swipe the BTC he sent to an address with a private key of 0xfacebeef. That could be found via an incremental search in under an hour of CPU search time on one computer. I note that compressed public keys are not being used in these examples - it's highly recommended to use them, since they reduce transaction size and cost. Regarding weak keys - there have been a lot of weak key generation techniques in bitcoin where hiding the public key won't do you any good.

lordnacho 9y ago
Just a warning for people, I was playing around with BTC the other day and not generating random entropy from urandom, just putting in a short string. I found my BTC was stolen immediately when I did this. It wasn't a lot of coins, since I was just testing, but it certainly cost me some debugging time as I wondered how the extra transaction had occurred. Basically, someone out there has already generated the keys corresponding to short strings and is keeping an eye on any transactions on them. Maybe more than one group, who knows?
- tylersmith 9y ago
  There are many of us with bots sweeping weak keys. Some of us give the coins back to a safe address, some people just keep it. It's like finding money on the sidewalk.
  - jacquesm 9y ago
    No, it's like picking money off the sidewalk when someone drops their coins and then running away.
    - tylersmith 9y ago
      It depends on if they "run away" and keep it, or if they return it to the proper owner in a secure manner.
  - baudehlo 9y ago

deleted 9y ago

[deleted]

ryan-c 9y ago

Looks like there was bitcoin left in the address he published the private key for until about 30 minutes ago. I hope that was a deliberate giveaway. https://blockchain.info/tx/2685ff794de17cebdf94eb0f111e8b8c03529a9ae628909cef4090663b54e565 https://blockchain.info/tx/2685ff794de17cebdf94eb0f111e8b8c0...

jameskegel 9y ago
As of the time of publishing, roughly ~8.58 USD.
samlewis 9y ago
I did deliberately leave that there in the hope someone might take it using what they'd learnt from the article. there's a short note about this in the conclusion to the article. From the "non whole" fee amount it looks as though someone might have just used some sort of wallet software to take it though, which is a shame.

sprt 9y ago

Wrt transactions, I don't understand why you need to send yourself the unspent BTCs. Why does it make things significantly easier?

iso-8859-1 9y ago
Because the miner almost always expects a fee, so why not just infer how high it is and you don't need to spend block bytes on it?
- sprt 9y ago
  Ok, but the unspent output takes space as well. I think you could just replace it with the fee. Not sure if I'm missing something or if it was just an arbitrary design decision.
  - samlewis 9y ago
    It has to do with the way transactions and the blockchain ledger works, reread the transaction part of the article and it might make more sense. Basically, transaction outputs can either be spent or unspent, you can't half spend an output (or perhaps more accurately, you can't spend a previous output twice).
    - sprt 9y ago
      Yes I understand that's how it works, but I don't get why it's important. Surely you could double spend an output as long as you don't exceed its value; and that looks easily verifiable.
      - samlewis 9y ago
        Ah, my bad. Sorry if I was being condescending in my previous reply then. I suspect it was a design decision, yeah. If outputs could be spent multiple times then you'd need to traverse the chain of outputs backwards to see how much an output has left in it. Bitcoin's implementation is less complex and more elegant, imo.