Here is one more thing to discuss, I think.
1. Flawed public key compression:There are a few transactions which use an uncompressed public key as input and then compress the key, but use a prefix of "02" where "03" would be used. Those transaction outputs are not spendabe by the user nor do they represent the initial address in any way, if base58 encoded.
Example:
Input: uncompressed public key
04e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee3419a40b939c24ac813c692a323ca5207a6fb387ffe28e48f706c95dbf46648f
Base58 encoded:
13NRX88EZbS5q81x6XFrTECzrciPREo821
Output: compressed with "02" instead of "03":
1JzhWo3tuReu8rsbhVPrBLxxGTcve6aaD
18 transactions (+ 3 invalid) are affected:
Transaction id Original input address
5885b1aa8938f234da483a5190084c3c425ab03363810e68b0214d358a8144c6 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8 INVALID
5fe5e0a2c7a4c9ae92708631b0559c32ebad33aa65d12d9d13b23869a1a68cbf 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8 INVALID
4842af86dac35a2c294f56511c7d08362330e82bd5fcae32c07119844e019b0a 14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd (mine)
ba63aa51cbf233a63db56b2dfb731c4f609b728125d1154fbc5453ec841c07cc 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb
3b08b5219e9dc8474b54d9d22fcdc7ccc03e916de313d306a5135ff607480cb6 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb INVALID
bc12d67c9403128a7effd9ff1da30dbcb3a47bc82207b2e93ea62de7ae91a4c9 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
e36099be9139bfe6a3a0a3f2b29a83b4cfe0c56d4fe58fd4e672a4bc9d4adae4 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
f6bb04e866fcf7a267f1af5659a7350a87b2c132ee1253757846c5be0b455a42 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb
8a8c2e7fe253fe8635d34ecc71510955d3a344546410db6961b35cd51809d3ea 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
f91f80606f96c0b0e5e30f2929e04a099b92c2dd26971180165d45d9b06a363e 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb
eef12413271bdda3446aac2209f26f01c35add0a18fcffce143cf298225a2375 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
f1897e2fa5b495b3e5dfd29fb30de63725d58e925ea7e6ef250066b5abde1bb8 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
5058febb5a048e021114534728a1aff7907b504ac47406067de81cd8384d8a07 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
e412453bde7abb42b3610beff5fad0fc3db3c4317a503914ab1e452e5fc326a5 13NRX88EZbS5q81x6XFrTECzrciPREo821
f8f166210911b28ef1cd720b57a94b43cd551203116c3abed84490d14200e191 13NRX88EZbS5q81x6XFrTECzrciPREo821
a3e4b7728835008b141c5f813e76416bd0876a50197bacafec8b039380ed36f1 13NRX88EZbS5q81x6XFrTECzrciPREo821
a47ddb72ebed729257bf29ca4907381551f6eb772b913f3895e5697673addeeb 13NRX88EZbS5q81x6XFrTECzrciPREo821
f8e53b52fa18e478fca931946bdf388ffcbecd9b053db3672f5289696e552739 13NRX88EZbS5q81x6XFrTECzrciPREo821
78735dfd07c20789a249063ab18b43516c5ac744c1b79612f9e5895773e707c4 13NRX88EZbS5q81x6XFrTECzrciPREo821
708d30405a58e1be0301e9475d0c9a23a9090d85e1fdf52808f90a8fe72f8a49 13NRX88EZbS5q81x6XFrTECzrciPREo821
8b0c75191564a937c4996702c425f9399c8d70742b44e4d9e306016d87bbc708 13NRX88EZbS5q81x6XFrTECzrciPREo821
2. No input reference in the outputs:There are 10 transactions (+ 3 invalid) with an output with a public key that is not the input and where the output is no data packet:
Transaction id Original input address
4805d3fba156e622cfdf47b12e68380b181cc96e9e6ef21076d9bc7e6704e336 14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd (mine)
55791fff99bbf40b8aeb5d0aac40e15bf0120bc5cce4b06c00c6626329c90fed 1donutMH4L7kdRqh4xvSvesfd3KFu3UNm
98314ebb0d96a98b5b52c891c8aac982e77420429450661b078a795051389d75 1donutMH4L7kdRqh4xvSvesfd3KFu3UNm
6784b73048de3ab36c08ee06897be92ccb20f9b288345f96b0681cbc5b014ad4 1gYs2kC58J7aRBRJ7CYqysBpYoT7b5i8H INVALID according to Masterchain
a7120ed05e1b42f48fec59d0a3b56202d15a0bb8272653f995ac584f16e67c09 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
f4d5e7a5af93b5091a2652719943c3a19f56cf6933d071a87f2bf87cba9a7f0a 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
31620c7e58f31a1833808f52eb240e4c4510994765f4d269bb2740ecfa136f9a 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
2ae17011888e9a2e6c752999774cd6d88feb7c0751abe72a602be89858e44f6a 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
b9e6b1f6f428441d7e91e7715ed4524de942b8d755367828e1d85ca850a9dc43 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
8c9027bfbee656c591ec87d233f0e338e623452519fbf8d76961e1afa480949c 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j INVALID according to Masterchain
38c37aec242e1054a366bbbe79fac2b01c392fe6c9c1732d25f54f0dbcc317dd 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j INVALID according to Masterchain
100e35e3fba087407a67e69ac60436f2b1f097823d083464ad26940d9fa06f6e 1Pa6zyqnhL6LDJtrkCMi9XmEDNHJ23ffEr (mine)
e308a5c9f7f035e3c1ed1abafdda85d9b790dbf8243f90484a9b25d6a7f8c8e7 1Pa6zyqnhL6LDJtrkCMi9XmEDNHJ23ffEr (mine)
The spec says:
- Has a single or the largest input signed by the sending address.
- Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address.
The above mentioned transactions are in conflict with those requirements.There are multiple transactions with more than one input, but in almost all cases the same input address is used. There are currently 5 simple send transactions with more than one different input addresses. Not a single valid multi sig transaction.
I personally dislike the allowence of different inputs (many with the same pubKey are fine), because such transactions requires to fetch all input transactions to extract the value to determine the highest one which would otherwise be not necessary.
I have no solution
how data packages can be safely identified and ordered and no implementation is currently able to parse a transaction with
unordered data packages.
But
if a given order is strictly required it would make the whole concept of sequence numbers more or less obsolete. I don't want to believe this though.
Here is my take:
1. Class A transactions are seperated and can be treated completey different. It's obsolete anyway, so workarounds or inefficiencies are not an issue.
2.
I suggest to disallow multiple inputs with different public keys. This does not invalidate any transaction up until now, it is much more painless and furthermore the identification of the input reference is solely possible via the input itself. Including the input reference as part of a multisig still makes a lot of sense to redeem the output, but that's not mutually exclusive.
3. Fixing the prefix issue of compressed public keys is advised.
4. It would be
very, very, very awesome, if there is a) a way to distinguish between data packages and non-data packages and b) if this is also possible, if data packages are not ordered. If this is the case, then including the pubKey as output would not require a special note nor would any malformated or additional pubKey in the outputs raise a conflict.
So the questions:What do you think about dropping the support for multiple inputs with different pubKeys (= different wallets) for class B transactions?
How should multi sig outputs be treated which are neither a valid input reference (e.g. due to flawed compression, compression or because it's simply junk) nor a valid data package?
Currently all this mostly affects transactions that were issued by devs and those conflicts did not yet lead to notable problems, but once it gets real, there might be no turning back anymore.
That's my biggest "fear".