<p>With block 602500 (about 2 weeks after v1.2.0 release) we enforce a new rule which represents a<br>
hard fork. Not updated nodes would see an out of sync dao state hash if a relevant transaction would<br>
happen again.<br>
Further (highly unlikely) consequences could be:<br>
If the BSQ output would be sent to a BSQ address the old client would accept that even it is<br>
invalid according to the new rules. But sending such a output would require a manually crafted tx<br>
(not possible in the UI). Worst case a not updated user would buy invalid BSQ but that is not possible as we<br>
enforce update to 1.2.0 for trading a few days after release as that release introduced the new trade protocol<br>
and protection tool. Only of both both traders would have deactivated filter messages they could trade.</p>
<p>Problem description:<br>
We did not apply the check to not allow BSQ outputs after we had detected a BTC output.<br>
The supported BSQ transactions did not support such cases anyway but we missed an edge case:<br>
A trade fee tx in case when the BTC input matches exactly the BTC output<br>
(or BTC change was <= the miner fee) and the BSQ fee was > the miner fee. Then we<br>
create a change output after the BTC output (using an address from the BTC wallet) and as<br>
available BSQ was >= as spent BSQ it was considered a valid BSQ output.<br>
There have been observed 5 such transactions where 4 got spent later to a BTC address and by that burned<br>
the pending BSQ (spending amount was higher than sending amount). One was still unspent.<br>
The BSQ was sitting in the BTC wallet so not even visible as BSQ to the user.<br>
If the user would have crafted a custom BSQ tx he could have avoided that the full trade fee was burned.</p>
<p>Not an universal rule:<br>
We cannot enforce the rule that no BSQ output is permitted to all possible transactions because there can be cases<br>
where we need to permit this case.<br>
For instance in case we confiscate a lockupTx we have usually 2 BSQ outputs: The first one is the bond which<br>
should be confiscated and the second one is the BSQ change output.<br>
At confiscating we set the first to TxOutputType.BTC_OUTPUT but we do not want to confiscate<br>
the second BSQ change output as well. So we do not apply the rule that no BSQ is allowed once a BTC output is<br>
found. Theoretically other transactions could be confiscated as well and all BSQ tx which allow > 1 BSQ outputs<br>
would have the same issue as well if the first output gets confiscated.<br>
We also don't enforce the rule for irregular or invalid txs which are usually set and detected at the end of<br>
the tx parsing which is done in the TxParser. Blind vote and LockupTx with invalid OpReturn would be such cases<br>
where we don't want to invalidate the change output (See comments in TxParser).</p>
<hr>
<h4>You can view, comment on, or merge this pull request online at:</h4>
<p> <a href='https://github.com/bisq-network/bisq/pull/3413'>https://github.com/bisq-network/bisq/pull/3413</a></p>
<h4>Commit Summary</h4>
<ul>
<li>Apply rule to not allow BSQ outputs after BTC output for regular txs</li>
</ul>
<h4>File Changes</h4>
<ul>
<li>
<strong>M</strong>
<a href="https://github.com/bisq-network/bisq/pull/3413/files#diff-0">core/src/main/java/bisq/core/dao/node/parser/TxOutputParser.java</a>
(67)
</li>
<li>
<strong>M</strong>
<a href="https://github.com/bisq-network/bisq/pull/3413/files#diff-1">core/src/main/java/bisq/core/dao/node/parser/TxParser.java</a>
(24)
</li>
</ul>
<h4>Patch Links:</h4>
<ul>
<li><a href='https://github.com/bisq-network/bisq/pull/3413.patch'>https://github.com/bisq-network/bisq/pull/3413.patch</a></li>
<li><a href='https://github.com/bisq-network/bisq/pull/3413.diff'>https://github.com/bisq-network/bisq/pull/3413.diff</a></li>
</ul>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/bisq/pull/3413?email_source=notifications&email_token=AJFFTNUFEEITQ62XT2OGZWDQOYEV7A5CNFSM4JBAOB5KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HR6QYMQ">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNSTLZBFLG46DHER3QTQOYEV7ANCNFSM4JBAOB5A">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AJFFTNVP3IBJHCQ2VJ54NBDQOYEV7A5CNFSM4JBAOB5KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HR6QYMQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/bisq/pull/3413?email_source=notifications\u0026email_token=AJFFTNUFEEITQ62XT2OGZWDQOYEV7A5CNFSM4JBAOB5KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HR6QYMQ",
"url": "https://github.com/bisq-network/bisq/pull/3413?email_source=notifications\u0026email_token=AJFFTNUFEEITQ62XT2OGZWDQOYEV7A5CNFSM4JBAOB5KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HR6QYMQ",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>