Hello. I am happy to report that the fork has today, starting with block
620000, activated successfully.
02C1 6A10: 00 61 99 99[28 91|00 00] 7C A7 4D 99 68 76 8F AA .a..(... |.M.hv..
02C1 6A20: 4F 59 E1 1A 90 4B 91 D5 0C 5C 0A 12 F2 A4 4D 20 OY...K.. .\....M
02C1 6A30: D3 EB 86 53 6A 8D C7 44 00 61 99 99[31 81|00 09] ...Sj..D .a..1...
02C1 6A40: 7B BE 91 AA 86 D2 3D 54 B6 59 00 E6 AB 02 E0 87 {.....=T .Y......
02C1 6A50: 20 73 E5 D3 FE 45 AE 08 F6 4D 53 8F BF 0E 6D 7D s...E.. .MS...m}
02C1 6A60: 00 62 00 00[00 00 00 13] 9D 62 45 AB EA 11 07 CF .b...... .bE.....
Full disclosure: Since the beginning of the token the code contained a small
mistake. This mistake should I say flaw was in the utxo tag mechanism. Briefly
every long P2WSH address that you pay to in Bitcoin, since segwit activated,
is tagged along with the block number it occured in as well as the transaction
number within the block and the output number within the transaction. Due to
practical limitations the limit can't be infinite but a small limit of 9999 was
chosen for the transaction number as well as limit of 9999 was chosen for the
output number. The problem is related to what happens when the limit is exceeded.
Fortunately we were using string contatenation so the number did not overflow
into the block counter. But still, it was possible to within a block to send
money using a huge transaction to two destinations A and B according to an intended
rules of the network the funds should go to A, yet the wallet would send them to
B instead. Example:
Pay to address a1 output number 1001 does not overflow, stays 1001
Pay to address b1 output number 10000, gets overflown to 1000
The funds are attributed to B because 1000 < 1001 even though B was paid later
in the block. a1 and b1 are haircomb teeth we assume other teeth were exploited
in the same way.
But there is a worse behavior namely duplicate utxo tags were possible. In
a well designed coin this causes coinburns, in a badly designed coin this is
an inflation vulnerability. So, luckily, we suffered only from unintended
coinburns. But for other misdesigned wallets this could be problem in the future.
Example:
Pay to address a1 output number 1000 does not overflow, stays 1000
Pay to address b1 output number 10000, gets overflown to 1000
We get duplicate utxo tag. The funds are tie-burned even though B was paid later
in the block. a1 and b1 are haircomb teeth we assume other teeth were exploited
in the same way.
Solution: Merge the two limits into one larger block-internal limit of 99999999.
We take transactions out of the picture and whole block is considered to be one
huge transaction. Only a block specific output number is used beyond this point.
The new limit cannot be exceeded due to 1MB (virtually 4MB segwit) block cap.
Because adversaries cannot anymore exploit the issue and pay an unaware user
misattributed funds, this means the adversary cannot entrench the issue into the
economy.
So, you can start transacting whith anyone, now.
anyway to make sure this was not exploited for inflation purpose in history?