10, 10 year old Bitcoins in 10 alternate universes!

[Coding Enthusiast]

I have been learning more about bitcoin and programming at the same time all the while having some fun with both. On bitcoin front I have been exploring the Digital Signature Algorithms and mainly focusing on elliptic curves, on programming front focusing on Inversion of Control and it has been letting me do stuff like this.

Since bitcoin is 10 years old today I chose 10 different bitcoin implementations and posted the results here.
There are 2 different Digital Signature Algorithms (ECDSA and ECSDSA) using 5 different curves hence 10 different coins. The algorithms being Elliptic Curve DSA that bitcoin is using and Elliptic Curve based Schnorr DSA. The list of them with additional information can be seen in the following table:

* Schnorr algorithms are based on the original 1991 paper in Journal of Cryptology not the sipa’s unofficial BIP. The reason is that the later has a Jacobi Symbol and I wasn't sure if I was calculating it correctly and I have no unit tests although my verify returns true.

To make it related to this occasion (the 10th bitcoin birthday) I chose the following “Easter egg” which can be found in the very first bitcoin block as a seed to find the first private key using a simple SHA512 hash.

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

To reduce the size of the key for each coin a simple % curve.N was performed.

Code:

prvbtc521: ctCJLpKQRGeEy1vfwURYJCwwP7AGkyo9V75f8K7DVTSdLaJ4cfMatnQUdZg6Dp3RyrBKm2HjrbsgzR1NmPEikMFB2Qxx6QSDr
prvbtc: cTf2PDXMK6fbZUAC4GV8N8wewnzurabVeXJ2JqvpZbMvcxDjZGyz
prvbtc192: ci9qEELh7Fba2YUP8HLAtaEwRuossREiMfXamMPNj
prvbtc384: Cs5Yoy2n2y7kVcwotu1kGfrhqnSjqhuMubCXQMggGS7q23HsnnNEAz5YYTCXy95AaK4YdW5C3Z

Here is the transaction with bitcoin (I'll broadcast the rest in the alternate universes!) https://www.blocktrail.com/tBTC/tx/7feef9bf65de07a391658e57a61ff9f3ba3b7dd8fce8f28fea38d0267cad89fc

I have not used any libraries, everything is my own implementation so it means it is not optimized and it may contain bugs. But it is interesting to say that the time signing operation takes is increasing with the curve size but with a whopping rise with last two ones which I believe is partly because of the a and b values of random curves compared to Koblitz curve. As for Schnorr the time is reduced about 5% because it doesn't have the multiplicative inverse modulo n. Of course Schnorr becomes more interesting when it involves verifying many signatures at the same time.

Transaction sizes for each curve, just for fun:

* Schnorr transaction sizes are the same with 1-2 byte difference.

Here is how bitcoin would look like with Schnorr (note that I believe Schnorr signatures will be implemented through SegWit with a new witversion but I am just guessing since I had no time reading the roadmap yet so I simply change the signature algorithm with Schnorr here):

Code:

hex:
01000000015a2647bfc3a43aa2104c8da0d9d71c8954826a6dd6f8e42df9cda6f96fb2e331000000006c493046022100bf560f18bddd23959b2600dbbfc8acdc8de8f747e01cd357f1dd2c1d5be9e875022100f932d8b2bf204b1b0a44a774099a0c670b44dcaccad489e124610d423984e5550121034a60644fb34922cfaef5648ab96593a2597d57d2aafaa698333995499c4fb113ffffffff01e2a69b00000000001976a914ecb20c627ad0e84456952666ed6c1d0c7eb9bc9388ac00000000

Serialized:

Code:

{
  "Version": 1,
  "TxInCount": 1,
  "TxInList": [
    {
      "Outpoint": {
        "TxId": "31e3b26ff9a6cdf92de4f8d66d6a8254891cd7d9a08d4c10a23aa4c3bf47265a",
        "TxHash": "5a2647bfc3a43aa2104c8da0d9d71c8954826a6dd6f8e42df9cda6f96fb2e331",
        "Index": 0
      },
      "ScriptSigLength": 108,
      "ScriptSig": "493046022100bf560f18bddd23959b2600dbbfc8acdc8de8f747e01cd357f1dd2c1d5be9e875022100f932d8b2bf204b1b0a44a774099a0c670b44dcaccad489e124610d423984e5550121034a60644fb34922cfaef5648ab96593a2597d57d2aafaa698333995499c4fb113",
      "Sequence": 4294967295
    }
  ],
  "TxOutCount": 1,
  "TxOutList": [
    {
      "Amount": 10200802,
      "PkScriptLength": 25,
      "PkScript": "76a914ecb20c627ad0e84456952666ed6c1d0c7eb9bc9388ac"
    }
  ],
  "LockTime": 0,
  "Flag": 0,
  "WitnessList": null
}

Happy 10^th birthday, bitcoin.

[1714818317]

1714818317

[1714818317]

1714818317

[1714818317]

1714818317

[1714818317]

1714818317

[1714818317]

1714818317

[Coding Enthusiast]

Here is the transaction for btc192:

Code:

hex:
01000000016d6ba7a66e3a3b4da23d291f9d3c21b4045aeaba0000000052373034021864ea0d8b3fafaceb9c075851a557cac98ede918af3c540d902181cfaf71070fe68e655e37e0a76d8b227df1dd6a28b96e5eb011902c624107ac3d3d017d0fa1ab3a76a0611b861b97352717f11ffffffff01e2a69b00000000001976a9149be2268ea730df2d740130c35f75e18709a3e26a88ac00000000

Serialized

Code:

{
  "Version": 1,
  "TxInCount": 1,
  "TxInList": [
    {
      "Outpoint": {
        "TxId": "baea5a04b4213c9d1f293da24d3b3a6ea6a76b6d",
        "TxHash": "6d6ba7a66e3a3b4da23d291f9d3c21b4045aeaba",
        "Index": 0
      },
      "ScriptSigLength": 82,
      "ScriptSig": "373034021864ea0d8b3fafaceb9c075851a557cac98ede918af3c540d902181cfaf71070fe68e655e37e0a76d8b227df1dd6a28b96e5eb011902c624107ac3d3d017d0fa1ab3a76a0611b861b97352717f11",
      "Sequence": 4294967295
    }
  ],
  "TxOutCount": 1,
  "TxOutList": [
    {
      "Amount": 10200802,
      "PkScriptLength": 25,
      "PkScript": "76a9149be2268ea730df2d740130c35f75e18709a3e26a88ac"
    }
  ],
  "LockTime": 0,
  "Flag": 0,
  "WitnessList": null
}

Here is the transaction for btc521:

Code:

hex:
0100000001a3c3da6490ed951c019723b5701acab524edafb3174c5c00220afc9c405d5b974aa9c5d1c134f77c9c3a9d6bc1d4494acc828ce84243da078e40451b574734ae00000000d04c8b3081870241744426278a6defed8a7f992ef8dd29638d09e6aa3162ec55054b6a1b548ea9d152f330ec8e85db5270198d18d1bf87bf088fb95776b99251959e555f035e17a6f9024200af953acce4583801d99c3c84f32df01392ae4c4f4b47ae3aae21306c1eba02b69032768895b4f308be8b26a3b4b4c17606b6c9f902dd9c825509274a6230a5109f0142026f3f5e111adacfe4a0e9f2536df34db0907cb5085a277b0da3c78905b7eed258791a94b713de18a6a13ba71fcf9bb40f79011dd01b1571f690273d67c5ef675a96ffffffff01e2a69b00000000004576a940d17fdb75bb04d2c59fb5b8d6ab090fe8a7fb5f779b9f3d1cfc716b72d174aa2dde7a200d4f686d1cebb210729684a15350ba0ec21016848600e8855bfe1b9dbb88ac00000000

Code:

{
  "Version": 1,
  "TxInCount": 1,
  "TxInList": [
    {
      "Outpoint": {
        "TxId": "ae3447571b45408e07da4342e88c82cc4a49d4c16b9d3a9c7cf734c1d1c5a94a975b5d409cfc0a22005c4c17b3afed24b5ca1a70b52397011c95ed9064dac3a3",
        "TxHash": "a3c3da6490ed951c019723b5701acab524edafb3174c5c00220afc9c405d5b974aa9c5d1c134f77c9c3a9d6bc1d4494acc828ce84243da078e40451b574734ae",
        "Index": 0
      },
      "ScriptSigLength": 208,
      "ScriptSig": "4c8b3081870241744426278a6defed8a7f992ef8dd29638d09e6aa3162ec55054b6a1b548ea9d152f330ec8e85db5270198d18d1bf87bf088fb95776b99251959e555f035e17a6f9024200af953acce4583801d99c3c84f32df01392ae4c4f4b47ae3aae21306c1eba02b69032768895b4f308be8b26a3b4b4c17606b6c9f902dd9c825509274a6230a5109f0142026f3f5e111adacfe4a0e9f2536df34db0907cb5085a277b0da3c78905b7eed258791a94b713de18a6a13ba71fcf9bb40f79011dd01b1571f690273d67c5ef675a96",
      "Sequence": 4294967295
    }
  ],
  "TxOutCount": 1,
  "TxOutList": [
    {
      "Amount": 10200802,
      "PkScriptLength": 69,
      "PkScript": "76a940d17fdb75bb04d2c59fb5b8d6ab090fe8a7fb5f779b9f3d1cfc716b72d174aa2dde7a200d4f686d1cebb210729684a15350ba0ec21016848600e8855bfe1b9dbb88ac"
    }
  ],
  "LockTime": 0,
  "Flag": 0,
  "WitnessList": null
}

[cellard]

So would you say that once we have Schnorr signatures operative we would have the best Bitcoin on all of these universes or the ones with the tx sizes a bit smaller are better without compromises on security?

Anyway I find interesting the thought of multiple universes. The theory that basically says there are unlimited universes in a fractal form would basically mean that there are infinite Bitcoin versions where satoshi decided to have 22 million coins instead of 21, or 20, or any other number. It is insanity to think about it so I prefer to focus on the task at hand (that is, our very and only Bitcoin, we already have enough work dealing with the forkers within this universe).

[Coding Enthusiast]

So would you say that once we have Schnorr signatures operative we would have the best Bitcoin on all of these universes or the ones with the tx sizes a bit smaller are better without compromises on security?

I was just having some fun with different Elliptic Curve Digital Signature Algorithms, I haven't even gotten to do explore the binary curves (F2m) or haven't even begun to mess around with RSA.
This wasn't meant for showing which is "better", but only to show the alternatives.

As for Schnorr, I see 3 benefits (there may be more):
- Speed of signing transactions
- Speed of verifying transactions and more importantly multiple transactions (like verifying a block or when you receive a tx message for your mempool)
- Size of multisignature signatures which would help scaling a lot.

I don't see any security issues with Schnorr. It is pretty much the same as ECDSA that we are currently using and it has been around nearly as long. The problem was with the fact that Schnorr was patented so everyone used the alternative which wasn't.

[buwaytress]

Going to have to throw my hands up and admit I don't really understand these... any other external factors taken into consideration, or are all alternate versions working on the same assumptions of today?

Are we saying that speed and size of transactions were all that affected adoption? And security itself wasn't actually the biggest consideration (or are we assuming Schnorr is also the most secure?).

[Coding Enthusiast]

Going to have to throw my hands up and admit I don't really understand these... any other external factors taken into consideration, or are all alternate versions working on the same assumptions of today?

The differences are in:
- The elliptic curve that was used which are all over Fp but have different variable values. This will affect the security and also is used in the following:
-- Calculation of `e` (based on size of the curve, for example for secp256k1 chances of trimming e is highly unlikely but in other curves it has a higher chance of happening, not a security disadvantage though)
-- Choice of hash function that was used for these alternatives and needs to match the size of the curve. The function itself is used for:
--- Getting transaction ID (for example in outpoint of btc521 in second post you can see the hash is a 64 byte one which is the result of a SHA512)
--- In rfc6979's HMAC function (for getting a deterministic k value)
--- Hash of the message for signing (for calculating e afterwards)

Are we saying that speed and size of transactions were all that affected adoption? And security itself wasn't actually the biggest consideration (or are we assuming Schnorr is also the most secure?).

I didn't get into the topic about security that much, and I'm no expert. I can't begin to assume why Satoshi chose this curve but it is a good one right in the middle. It offers a good enough security and it is fast. And by that time ECDSA was more popular than ECSDSA.
When security is concerned choice of the curve is based the "strength" of the curve. Bitcoin's curve offers 128 bits of security and according to SEC1 document it offers security beyond 2030 (which is just an estimation made in 2009).
As for Schnorr, the security (AFAIK) is the same because you are still using the same curve with the same hash functions. The only difference is in calculation of the signature which is still pretty much the same. Schnorr (whether it is the original 1991 patented one or any of the other 4 alternatives or if it is the Sipa's implementation) is getting rid of 2 multiplicative inverse modulo n which exist in ECDSA and adds some hashing in there but everything else is the same. You still choose the same random k, multiply that with a point (G) for calculation of r and get s based on that.

[darosior]

Going to have to throw my hands up and admit I don't really understand these... any other external factors taken into consideration, or are all alternate versions working on the same assumptions of today?

The differences are in:
- The elliptic curve that was used which are all over Fp but have different variable values. This will affect the security and also is used in the following:
-- Calculation of `e` (based on size of the curve, for example for secp256k1 chances of trimming e is highly unlikely but in other curves it has a higher chance of happening, not a security disadvantage though)
-- Choice of hash function that was used for these alternatives and needs to match the size of the curve. The function itself is used for:
--- Getting transaction ID (for example in outpoint of btc521 in second post you can see the hash is a 64 byte one which is the result of a SHA512)
--- In rfc6979's HMAC function (for getting a deterministic k value)
--- Hash of the message for signing (for calculating e afterwards)

Are we saying that speed and size of transactions were all that affected adoption? And security itself wasn't actually the biggest consideration (or are we assuming Schnorr is also the most secure?).

I didn't get into the topic about security that much, and I'm no expert. I can't begin to assume why Satoshi chose this curve but it is a good one right in the middle. It offers a good enough security and it is fast. And by that time ECDSA was more popular than ECSDSA.
When security is concerned choice of the curve is based the "strength" of the curve. Bitcoin's curve offers 128 bits of security and according to SEC1 document it offers security beyond 2030 (which is just an estimation made in 2009).
As for Schnorr, the security (AFAIK) is the same because you are still using the same curve with the same hash functions. The only difference is in calculation of the signature which is still pretty much the same. Schnorr (whether it is the original 1991 patented one or any of the other 4 alternatives or if it is the Sipa's implementation) is getting rid of 2 multiplicative inverse modulo n which exist in ECDSA and adds some hashing in there but everything else is the same. You still choose the same random k, multiply that with a point (G) for calculation of r and get s based on that.

Hi,

Schnorr signatures are in a way more secure :

Schnorr signatures have a security proof, which is not true for ECDSA. In addition, they are also non-malleable, so a third-party that does not have access to a private key cannot modify the signature without invalidating it.

More about them here.

[buwaytress]

Are we saying that speed and size of transactions were all that affected adoption? And security itself wasn't actually the biggest consideration (or are we assuming Schnorr is also the most secure?).

I didn't get into the topic about security that much, and I'm no expert. I can't begin to assume why Satoshi chose this curve but it is a good one right in the middle. It offers a good enough security and it is fast. And by that time ECDSA was more popular than ECSDSA.
When security is concerned choice of the curve is based the "strength" of the curve. Bitcoin's curve offers 128 bits of security and according to SEC1 document it offers security beyond 2030 (which is just an estimation made in 2009).
As for Schnorr, the security (AFAIK) is the same because you are still using the same curve with the same hash functions. The only difference is in calculation of the signature which is still pretty much the same. Schnorr (whether it is the original 1991 patented one or any of the other 4 alternatives or if it is the Sipa's implementation) is getting rid of 2 multiplicative inverse modulo n which exist in ECDSA and adds some hashing in there but everything else is the same. You still choose the same random k, multiply that with a point (G) for calculation of r and get s based on that.

Thanks for that explanation and yes, I think the security assessment of beyond 2030 still stands today as it was a conservative estimate... also something that proponents of quantum computing threats forget (in that the estimate took this into account as well).

And I think, for as long as security improvements and/or upgrades use estimations that try to stay ahead of the curve, it may never be an important weight for choosing after all!

[cellard]

So would you say that once we have Schnorr signatures operative we would have the best Bitcoin on all of these universes or the ones with the tx sizes a bit smaller are better without compromises on security?

I was just having some fun with different Elliptic Curve Digital Signature Algorithms, I haven't even gotten to do explore the binary curves (F2m) or haven't even begun to mess around with RSA.
This wasn't meant for showing which is "better", but only to show the alternatives.

As for Schnorr, I see 3 benefits (there may be more):
- Speed of signing transactions
- Speed of verifying transactions and more importantly multiple transactions (like verifying a block or when you receive a tx message for your mempool)
- Size of multisignature signatures which would help scaling a lot.

I don't see any security issues with Schnorr. It is pretty much the same as ECDSA that we are currently using and it has been around nearly as long. The problem was with the fact that Schnorr was patented so everyone used the alternative which wasn't.

Indeed Schnorr is pretty cool, however, it is going to be interesting to see how it gets implemented, since any additions within the software are always very controversial.

From my research it could be added without the miners being involved (unlike the segwit clusterfuck) so I assume it would be an UASF?

For me the way things get activated are as interesting as the tech itself because of the game theory involved and watching it unfold is popcorn worthy.