Distribute burningman role to contributors who burned bsq

[HenrikJannsen]

Implements bisq-network/proposals#390

Based on #6404

Starts at commit 33c08c7

[HenrikJannsen]

Rebased on master

[HenrikJannsen]

From my side its complete now. I continue on another new PR for accounting of the received BTC but that should not have implications on that code. I will do a final in depth testing once all is complete but I tested that PR to some good extent.

Please do not merge before DAO voting has accepted the proposal.

[HenrikJannsen]

Proposal got accepted by DAO voting: bisq-network/proposals#390 (comment)

[HenrikJannsen]

Before merging please coordinate. There will be another PR and the activation data and some other data need to be finalized before merge.

[sqrrm]

Is 80 bytes going to be relayed?

[HenrikJannsen]

https://www.talkcrypto.org/blog/2016/12/30/op_return-40-to-80-bytes/

https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch05.html

OP_RETURN was initially proposed with a limit of 80 bytes, but the limit was reduced to 40 bytes when 
the feature was released. In February 2015, in version 0.10 of Bitcoin Core, the limit was raised back to 
80 bytes. Nodes may choose not to relay or mine OP_RETURN, or only relay and mine OP_RETURN 
containing less than 80 bytes of data.

Not 100% clear if there might be issues with nodes not relaying, but seems that 80 bytes is standard limit.

[sqrrm]

I saw this comment:

https://stackoverflow.com/questions/24845429/maximum-size-of-data-bitcoin-op-return-tx-can-handle

Please note that the up to 80 part is misleading: one data push can handle up to 75 bytes. Therefore OP_RETURNs with 76-to-80 bytes need special handling: encoded with OP_PUSHDATA1 with 1-byte length. More details: bitcoin.stackexchange.com/questions/116080/… – 
Adam B
Nov 22 at 14:32

https://bitcoin.stackexchange.com/questions/116080/tx-with-op-return-with-77-bytes-of-data-refused-by-node/116083#comment132105_116083

UPDATE: The first version of this answer suggested using two data pushes, updated to use OP_PUSHDATA1.

Further research has clarified the issue:

OP_RETURN max data length is 80 bytes, however
Maximum bytes in one push data is 75 bytes.
Therefore data of sizes between 76 to 80 need to be encoded with OP_PUSHDATA1!

The script in this transaction is in fact invalid, 6a 4d 53 57 should be interpreted as OP_RETURN OP_PUSHDATA2 53 57, after which 22355 (0x5753) bytes are expected.

Correct encoding would be to use OP_PUSHDATA1 for data of length 76 to 80 bytes.

50 6a 4c 4d <77 bytes> OP_RETURN OP_PUSHDATA1 4d <77 bytes>

[HenrikJannsen]

Rebased on master.

[sqrrm]

Should probably be called adjustedBurnAmountShare for clarity. It's now possible that some receivers get more than their max allowed, although only by a few satoshis.

[HenrikJannsen]

Yes, I think it does not really add a risk as its only small amounts

[sqrrm]

I saw this comment:

https://stackoverflow.com/questions/24845429/maximum-size-of-data-bitcoin-op-return-tx-can-handle

Please note that the up to 80 part is misleading: one data push can handle up to 75 bytes. Therefore OP_RETURNs with 76-to-80 bytes need special handling: encoded with OP_PUSHDATA1 with 1-byte length. More details: bitcoin.stackexchange.com/questions/116080/… – 
Adam B
Nov 22 at 14:32

https://bitcoin.stackexchange.com/questions/116080/tx-with-op-return-with-77-bytes-of-data-refused-by-node/116083#comment132105_116083

UPDATE: The first version of this answer suggested using two data pushes, updated to use OP_PUSHDATA1.

Further research has clarified the issue:

OP_RETURN max data length is 80 bytes, however
Maximum bytes in one push data is 75 bytes.
Therefore data of sizes between 76 to 80 need to be encoded with OP_PUSHDATA1!

The script in this transaction is in fact invalid, 6a 4d 53 57 should be interpreted as OP_RETURN OP_PUSHDATA2 53 57, after which 22355 (0x5753) bytes are expected.

Correct encoding would be to use OP_PUSHDATA1 for data of length 76 to 80 bytes.

50 6a 4c 4d <77 bytes> OP_RETURN OP_PUSHDATA1 4d <77 bytes>

[HenrikJannsen]

Ok, I reduce the opReturn to 40 bytes. Its anyway just a new feature without concrete use case so far and an only UI thing.
The opReturn size limit issue got heavily mis-managed by the Bitcoin community. Would not like to know how many dev hours have been wasted for that...

[HenrikJannsen]

Rebased on master

[sqrrm]

No more comments at the moment, will have to test it but code wise I think it looks good.

[ghost]

In regtest, the first person to burn is has a suggested amount in the range of a few thousand BSQ. Thereafter, burn targets are much smaller than what the first BM burned. e.g. Alice burns 2000 BSQ. All other BMs will only be allowed to burn 220 BSQ. Soon after, no one can burn anything, even if they go through several cycles of compensation.
It does not seem right, and maybe its because I'm missing some setup in regtest. Could it be due to there not being any proof of burns from the legacy BM? How would I go about simulating burns from the legacy BM, address 2MzBNTJDjjXgViKBGnatDU3yWkJ8pJkEg9w ?

[ghost]

Why are these burningman hashes hard-coded?

[HenrikJannsen]

Those are the hashes in the opReturn at burn txs of the BM to tag different use cases (btc fee, del payout tx to refund agent, del payout tx to trader)

[ghost]

Same again, hardcoded? I have to replace it with the relevant hashes from my database in order to pick up the legacy burningman's activity.

[HenrikJannsen]

You mean for testing it with regtest?

[ghost]

Yes, Regtest. I'm confused as to the necessity for hardcoding those hashes: if BM3 does a fee burn, I would have expected it to get integrated in real time, instead of pasting into the sourcecode.

[HenrikJannsen]

The burn tx opReturn data are arbitrary bytes. One can add some preimage which gets hashed in the UI, and that is what the BM is doing to tag the diff. burn txs to groups. So this helps us to filter for burn txs from btc fees and those for DPTs.

[HenrikJannsen]

Close that as #6423 is th final PR and based on that.