As my offline Bitcoin signer nears completion, it's a good time to introduce just what Bitcoin transactions are anyway, how they are signed, and not least of all how it could go horribly wrong if we're not careful. This first part will cover the basics that I consider required knowledge for anyone who handles the currency.
A Bitcoin transaction is a message with particular structure and binary encoding rules,(i) specifying the transfer of given quantities from one set of accounts to another.
Transactions are composed of inputs and outputs. Each output specifies a monetary value and a destination address.(ii) Each input contains a reference to a previous transaction output(iii) and a signature authorizing its spending. In a quirk of implementation, the "accounts" mentioned above don't explicitly exist in the system; outputs are considered either unspent or spent in full by inclusion in a subsequent transaction. Your available balance, then, is the total value of unspent outputs for which you are able to issue valid signatures. Since the amount to be sent isn't usually an exact sum of previous outputs, a "change" output is added so as to overshoot and send the excess back to the original owner.
Observing that the scheme as presented so far rests on the strength of the signature, let's briefly expand on that concept, leaving the mathematical details as a black box for present purposes. A digital signature scheme provides three high-level operations: key generation, signing, and verification. Key generation takes some cryptographic entropy as input and produces a public/private key pair. Signing takes a fixed-length message hash, a private key, and possibly some further entropy and produces a signature. Verification answers whether a purported signature is valid for a given hash and public key. This gives a high degree of confidence that the signature could only have been issued by someone with knowledge of the private key (as long as some underlying unproven mathematical assumptions hold, which they appear to have so far despite ample incentive to break them). Note the distinct advantage over traditional pen-and-paper signatures: simply seeing one does not grant an ability to forge it or pass it off as covering some other message, despite the susceptibility of digital information to perfect copying and easy modification.
To be continued.
- Due to an unfortunate misallocation of brain cycles by Satoshi and the others who imagined themselves Bitcoin developers in the early days, there's a whole cocktail of encodings with, for example, at least four different ways to represent integers. While this makes for some added implementation complexity, the details aren't especially important for normal usage. [^]
- Technically a "script", but for simplicity we'll consider only the standard "pay-to-pubkey-hash" form. [^]
- Except in the case of "coinbase" transactions which issue mining rewards. [^]
[...] on article on Bitcoin transactions and their signing that's building toward a series of publications presenting the [...]
Pingback by TMSR OS, February 2020 Statement « Dorion Mode — 2020-03-04 @ 07:21
[...] outlined the shape of the building block provided by digital signatures, we now face the potential problem [...]
Pingback by Bitcoin transactions and their signing, 2: attachment « Fixpoint — 2020-03-04 @ 20:10
Hey I know this is off topic but I was wondering if you
knew of any widgets I could add to my blog that automatically tweet my newest twitter updates.
I've been looking for a plug-in like this for quite some time and was hoping maybe you would
have some experience with something like this. Please let me know if
you run into anything. I truly enjoy reading your blog and I
look forward to your new updates.
my page: บล็อกเชน
Comment by บล็อกเชน — 2020-10-18 @ 01:44
Well this sounds like SEO spamming but it's so very polite! So:
Dear Mr. or Ms. Unicode Squiggles,
I'm not seeing any original content on your "blog", though I am seeing a "Mix doesn't support your web browser. For a better experience, we recommend using another browser." Perhaps you ought to be remedying these problems before getting into bird feeding hobbies.
Yours,
Jacob
Comment by Jacob Welsh — 2020-10-23 @ 19:04
[...] some more technical details regarding bitcoin transactions check out jfw's series "bitcoin transactions and their signing". This transaction is commonly called a coinbase transaction. A company called "Coinbase" took this [...]
Pingback by Receiving/Sending Bitcoins To/From An Offline Wallet, A Basic Explanation « whaack — 2021-03-04 @ 17:13
[...] the code pertaining to minimum fees, which would sometimes get applied when originating or relaying transactions, depending on output values, the alignment of the planets, the precession of the equinoxes and god [...]
Pingback by A tetrad of tuneups for bitcoind « Fixpoint — 2021-11-13 @ 16:03
[...] Not bad... but on this quest, each question answered only led to more questions, at least for a few rounds before I was satisfied. What floored me when looking at that trace was that an incoming block that passed the cursory checks in CBlock::CheckBlock would get duly written to disk as well as the in-memory block index and its backing database, before ever getting to CBlock::ConnectBlock, the part that does the heavy lifting of checking transaction references and signatures! [...]
Pingback by Mapping the bitcoind block acceptance code, with bonus patch for index access « Fixpoint — 2022-03-22 @ 04:11