LOL. BitcoinCashABC has out-of-order transactions

amaclin1

sr. member

Activity: 770

Merit: 305

Quote from: achow101 on November 16, 2018, 02:39:27 PM

You don't and just trust the miners that it is correct. That's the bcash model after all Grin

This model is suitable for all cryptos (including the Bitcoin itself).
People just want to use it for increasing their own national (fiat) money
Nobody cares what is under the cover.

Tonstar

member

Activity: 434

Merit: 10

Quote from: amaclin1 on November 16, 2018, 03:25:39 PM

Quote from: odolvlobo on November 16, 2018, 02:57:49 PM

the validator checks transaction 1db6...cd51 and verifies that its input matches output 0 of transaction c660...f617

I have a block and parse it from begin to end. Some pseudocode:

Code:

const int count ( rawdata.getTxCount ( ) );
for ( int i ( 0 ); i < count; i++ )
{
   const Transaction tx ( rawdata.getTransaction ( ) );
   // validate and update current state
}

In fact, I definitely able to rewrite my code.
I am just wondering - what is the reason to store transactions in alphabet order of their txid?
As far as I know, the client works with UTXO database, not with serialized blocks.

that part of human inventions is very interesting nd i want to widsh ypu good luck in all your work and vusiness just go on

Tonstar

member

Activity: 434

Merit: 10

Quote from: amaclin1 on November 16, 2018, 11:12:38 AM

Sorry for posting about alt-coin.

Looking into new "technologies". One more rule is broken. Transactions in block are in alphabet order.
This cause that spending comes earlier than funding. For example: block #556933
https://blockdozer.com/block/000000000000000000f3d1e6172916cad0a78cffa4e95ce2deb834f546103ffa

funding transaction https://blockdozer.com/tx/c660e155ed46c7e24e7fd9d7bb815f764447578d1ea74c2a531fc0d07552f617
is #78 in block, but spending the 0-th output of it is transaction
https://blockdozer.com/tx/1db66caf454642568895c1558e61644cca0dcee00886c661d24aa7c5a29fcd51
which has position #13 in the same block.

LOL Grin

How do you verify such blocks?

well j th9nk taht we should look fpr things taht will happen next and i believe tat we must see tje world statictics for this

amaclin1

sr. member

Activity: 770

Merit: 305

Quote from: odolvlobo on November 16, 2018, 02:57:49 PM

the validator checks transaction 1db6...cd51 and verifies that its input matches output 0 of transaction c660...f617

I have a block and parse it from begin to end. Some pseudocode:

Code:

const int count ( rawdata.getTxCount ( ) );
for ( int i ( 0 ); i < count; i++ )
{
   const Transaction tx ( rawdata.getTransaction ( ) );
   // validate and update current state
}

In fact, I definitely able to rewrite my code.
I am just wondering - what is the reason to store transactions in alphabet order of their txid?
As far as I know, the client works with UTXO database, not with serialized blocks.

odolvlobo

legendary

Activity: 4298

Merit: 3209

Quote from: amaclin1 on November 16, 2018, 01:44:21 PM

Quote from: odolvlobo on November 16, 2018, 01:09:22 PM

It is not necessary to store transactions in order of dependency. I can see how storing the transactions in numerical order by hash would improve performance.

This is not an answer for my question. How do you verify the validity of such block?

The order of the transactions does not affect the process for checking validity. In your example, the validator checks transaction 1db6...cd51 and verifies that its input matches output 0 of transaction c660...f617 regardless of where that transaction is -- in the same block or in an earlier block.

No rules are broken. The only positional requirement is that the input can't reference an output in a future block.

achow101

staff

Activity: 3374

Merit: 6530

Just writing some code

Quote from: amaclin1 on November 16, 2018, 11:12:38 AM

How do you verify such blocks?

You don't and just trust the miners that it is correct. That's the bcash model after all Grin

But actually, to verify such blocks, you could do it in multiple passes. In each pass, you verify the transactions and skip the ones where the inputs are missing from the UTXO set. As you verify, the UTXO set is updated. Then you try to verify the skipped transactions again and so on. You would do this until there are no unverified transactions left, or until the UTXO set is not updated after a pass over the unverified transactions. At that point, all of those unverified transactions are invalid because their inputs are not in the UTXO set and the inputs are not from a transaction that is in the block.

amaclin1

sr. member

Activity: 770

Merit: 305

Quote from: odolvlobo on November 16, 2018, 01:09:22 PM

It is not necessary to store transactions in order of dependency. I can see how storing the transactions in numerical order by hash would improve performance.

This is not an answer for my question. How do you verify the validity of such block?

odolvlobo

legendary

Activity: 4298

Merit: 3209

It is not necessary to store transactions in order of dependency. I can see how storing the transactions in numerical order by hash would improve performance.

amaclin1

sr. member

Activity: 770

Merit: 305

Sorry for posting about alt-coin.

Looking into new "technologies". One more rule is broken. Transactions in block are in alphabet order.
This cause that spending comes earlier than funding. For example: block #556933
https://blockdozer.com/block/000000000000000000f3d1e6172916cad0a78cffa4e95ce2deb834f546103ffa

funding transaction https://blockdozer.com/tx/c660e155ed46c7e24e7fd9d7bb815f764447578d1ea74c2a531fc0d07552f617
is #78 in block, but spending the 0-th output of it is transaction
https://blockdozer.com/tx/1db66caf454642568895c1558e61644cca0dcee00886c661d24aa7c5a29fcd51
which has position #13 in the same block.

LOL Grin

How do you verify such blocks?

Topic: LOL. BitcoinCashABC has out-of-order transactions (Read 155 times)