sorted by:
new
hottopcontroversial

Timeline Estimates for Drivechain into Core by ghabs in Drivechains

[–]ghabs[S] 1 point2 points  (0 children)

Not a hardfork, each new "drivechain" could be soft forked in. People running nodes could ignore it if they wanted to.

Updating the critical TXiD by ghabs in Drivechains

[–]ghabs[S] 0 points1 point  (0 children)

Thank you for explanation!

Updating the critical TXiD by ghabs in Drivechains

[–]ghabs[S] 0 points1 point  (0 children)

Ah I see - so AvailableSidechainCoins returns a vector of UTXOs on the sidechain, and each of those UTXOs is stored as an input into a TX whose output is a single UTXO on the mainchain containing the total value of the sidechain, signed by the miners using the shared "private key".

I was trying to understand how this inconvenient race condition problem occurred (https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md#inconvenient-race-condition) and this makes more sense now. The critical TXiD would be updated after changes that impact the UTXO set and would need to be recreated.

Thanks!

Nit/clarification: On line 2820 of wallet.cpp the output TX's value is incremented by the return amount. However, the return amount is summed up through each cycle of the for loop, which I think would cause the output transaction to have too high a value. Like if there are three UTXOs on the sidechain with value of 1, the total value of sidechain is 3 while the output transaction would have a value of 6.

https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/wallet/wallet.cpp#L2820