Live data from Hacker News

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

samlewis.me

51–60 of 67 posts

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

#51
post #49

Earlier quoted context omitted.

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).

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.

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.

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

#52
post #3

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.

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.

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

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

#53

Earlier quoted context omitted.

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 cor…

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.

No, it's like picking money off the sidewalk when someone drops their coins and then running away.

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

#54
post #3

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.

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.

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.

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

#55
post #40

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

The high-level meaning of a transaction is to send all the contents of an address. So if you only want to send partial payment, then you need two transactions - one to the foreign destination address and one back to yourself for the remaining funds. The analogy is closer to law and property title, rather than the mathematical/accounting actions of addition or subtraction.

In fact addresses don't really exist, other than as named state in the chain of title. It is the prior, unspent transaction output (utxo) that is unlocked during a transfer, and not some abstract bitcoin address.

Other blockchains, can and do handle these things differently.

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

#56
post #3

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.

It should say This is also why address reuse in Bitcoin is "discouraged" 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 "public key" of that address being exposed The reason being without revealing public key, with only the bitcoin address the attacker first need to guess the public key from the ad…

I was under the impression that ecdsa was potentially broken by quantum computers, but SHA-256 was not. Is that not the case?

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

#57

Earlier quoted context omitted.

It should say This is also why address reuse in Bitcoin is "discouraged" 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 "public key" of that address being exposed The reason being without revealing public key, with only the bitcoin address the attacker first need to guess the public key from the ad…

I was under the impression that ecdsa was potentially broken by quantum computers, but SHA-256 was not. Is that not the case?

Yes, in theory. See https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Qu...

ECDSA is vulnerable to a modified version of Shor's quantum integer factorization algorithm. However, nobody on Earth is known to be close to producing such a computer. Adiabatic quantum computers like the ones produced by D-Wave are not known to be capable of running Shor's algorithm. See https://en.wikipedia.org/wiki/Adiabatic_quantum_computation

SHA-256 and hashing algorithms have no known quantum attack against them, but one could theoretically gain a sqrt(n) advantage in brute-force search using Grover's quantum search algorithm. https://en.wikipedia.org/wiki/Grover%27s_algorithm

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

#58

Earlier quoted context omitted.

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 cor…

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.

This is like admitting to stealing things from people who leave their houses unlocked. If you think that is all good then you need to re-evaluate your life choices.

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

#59

Earlier quoted context omitted.

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 cor…

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.

It's more like stealing from an unlocked locker at a public pool.

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

#60

Earlier quoted context omitted.

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 cor…

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.

A lot of people are equating this to theft. While I can see their point, the concept of ownership in bitcoin is closely tied to control of the private keys. In this case many people control certain weak private keys so in a way you are giving your money away by sending to these addresses.
Post reply on HN