Delayed confirmations for some IBO transactions created by BlackCoin More
The BlackCoin More wallet in some circumstances created burn transactions which were rejected by most staking nodes, resulting in much delayed confirmations. The problem was much less severe with ordinary transfer transactions.
There are two reasons for delayed confirmations which interfered here.
Discrepancies in fee policies
BlackCoin More in default configuration seems to calculate fees for created transactions as the maximum of the following two values:
- 0.0001 BLK
- size in bytes × 0.0001 BLK.
Meanwhile, the Original wallet in default configuration calculates minimum required fee as (1 + floor(size in bytes / 1000)) × 0.0001 BLK. The relevant line of code: https://gitlab.com/blackcoin/blackcoin/blob/91b85b037c544017a8834b1e13bc4f3f56944f2d/src/main.cpp#L588
With transaction sizes less than 1000 bytes those policies are compatible. Starting from 1000, More generates lower transaction fees than a typical Original node wills to accept in a block.
Discrepancies in the datacarriersize option
The Original wallet sets default limit of data associated with burn transactions to 15000 bytes since version 1.2.5 (commit blackcoin/blackcoin@c1297b17). The More wallet sets default limit of data associated with burn transactions to 15000 since commit blackcoin/blackcoin-more@86155bfa, included in version v220.127.116.11-067783fa70 (there are two versions numbered 18.104.22.168 and this is the later of them). In both cases, default values used by previous wallet versions were insufficient for accepting an Ercoin IBO transaction.
We can get an idea about many blocks during the IBO were created using the Original and More wallets by looking at the block version field. To store block version numbers in a file named
ibo-block-versions, we can execute the following command in Fish shell:
for height in (seq -f '%.0f' 2804220 2842962) blackcoind getblockbynumber $height | jq .version end > ibo-block-versions
Then by running
sort ibo-block-versions | uniq we get distinct values for this field:
- 536870912 (reportedly associated with BlackCoin More)
- 7 (reportedly associated with BlackCoin Original)
Then we can count occurences of these two versions:
grep 536870912 ibo-block-versions | wc -lresults in
grep 7 ibo-block-versions | wc -lresults in
Block versions do not contain data about specific wallet versions, so we can only estimate these based on other data.
How it affected the IBO?
|Transaction||Mineable by a typical Original wallet < 1.2.5||Mineable by a typical Original wallet ≥ 1.2.5||Mineable by a typical More wallet < v22.214.171.124-067783fa70||Mineable by a typical More wallet ≥ v126.96.36.199-067783fa70|
|Standard transfer, generated by the Original wallet|
|Standard transfer, generated by the More wallet, < 1000 bytes|
|Standard transfer, generated by the More wallet, ≥ 1000 bytes|
|Ercoin IBO transaction, generated by the Original wallet|
|Ercoin IBO transaction, generated by the More wallet, < 1000 bytes|
|Ercoin IBO transaction, generated by the More wallet, ≥ 1000 bytes|
Therefore large transactions created using the newest version of the More wallet were mineable only by nodes using that particular wallet version (which was released on 2019-11-11). A worst case scenario would possibly look like that:
- Someone makes a test burn of a small amount of coins and sees that it is confirmed relatively quickly.
- Some time later, he makes a burn of the rest of the coins, consisting of many inputs and therefore forming a transaction ≥ 1000 bytes. This time the confirmation takes so long that the deadline is exceeded.
Did this scenario actually happen? We can look at two related transactions:
ef861d1d7af665c49c0f77119e28ae618b28e22309488a723af82b6b8cac7666, which burned 3 BLK. It was 279 bytes long and paid a fee of 0.0001 BLK. Its timestamp is Sat Dec 7 11:13:43 UTC 2019 and it is contained in block
381176f46b695d75651a2bf3a356c11a4d2399ae3b6bd48bc1a894bb92fca867with timestamp of Sat Dec 7 11:18:08 UTC 2019.
4aedfffc7bb90589cef0f8919165169824efa2caeb99f842650e56bff1218a76, which burned 10651.1473 BLK. It was 2018 bytes long and paid a fee of 0.0002018 BLK (Original wallet would require 0.0003 BLK). Its timestamp is Sat Dec 7 22:10:38 UTC 2019 and it is contained in block
258703648d4fc5a55d48420020b578f8d2d43388e73c5344d75fd7471a58ea0bwith timestamp of Sun Dec 8 00:07:28 UTC 2019.
(I obtained the timestamps from a local BlackCoin node. It seems that the explorer at https://chainz.cryptoid.info/blk gives different results, syncing transaction timestamps with block timestamps).
What should we do with it?
I see at least two possible solutions:
- Do nothing, treat block time as normative.
- Allow transactions with timestamps before the deadline.
Advocating for ⒈, we could say that an user is responsible for choosing a wallet and if he chooses one which is defective (creates transactions with fee too low to be confirmed in reasonable time), then it’s his fault.
Advocating for ⒉, we could say that: The More wallet was linked on the blackcoin.org website which was linked in our README. This fee-related issue was not documented in neither of those two places (nor in any other place, according to my limited knowledge). BlackCoin is not an internal part of Ercoin, it is used only for distribution. The requirement of meeting a block time was made with the implicit assumption that the BlackCoin ecosystem (wallet, network nodes) will behave in a way that provides confirmations in a reasonably predictable time. In this case confirmation time could largely differ even based on whether a wallet had been opened for large periods of time or not (staking can split transaction outputs, resulting in larger transaction size later). We shouldn’t expect future Ercoin users to be BlackCoin hackers which are able to individually predict and resolve such issues. Therefore we may address this issue by falling back to trasaction timestamp being used to determine time in case of corner cases. Since Ercoin has not launched yet, there is a room for that.
In case of choosing ⒉, we should probably pretend that the transaction paid fees sufficient for being mined before the deadline, deducing a relevant amount from output for the purpose of the IBO. Otherwise paying a lower fee would be slightly beneficial.
Another question is how to decide what to do. If there is one prevailing solution found, then maybe we should just implement that. Otherwise we may want to do a voting by elected validators. We could use the protocol field in the vote transactions for that purpose. Fortunately there seems to exist just one problematic transaction, not associated with a locked address (this should be confirmed by checking also previous burns), so a voting won’t generate a chicken-egg problem. Depending on how quickly we come to a conclusion, we may want/need to delay the genesis time.
For the sake of completeness, there are also burn transactions confirmed after the deadline with transaction timestamps also being after the deadline. But these seem to be evident errors of users just being late.