Blockchain trust requirement - bitcoin vs ripple vs bitshares

[monsterer]

In summary to the OP, the way the consensus on the order matching is arrived at is via the resulting transactions, since there is no actual 'trade' transaction.

[xeroc]

Semi related q.
In a 7 day( 200+ transactions) study i found that 25% -30% of all of my market transactions were not included in a block in 45 seconds or more (4-5 felegates+)
What might be the reason forthat?
Is it better or is it worse to re-broadcast such sticky txs?
Thanks.

I honestly have no idea

paging @vikram

[zerosum]

Semi related q.
In a 7 day( 200+ transactions) study i found that 25% -30% of all of my market transactions were not included in a block in 45 seconds or more (4-5 felegates+)
What might be the reason forthat?
Is it better or is it worse to re-broadcast such sticky txs?
Thanks.

[xeroc]

But if B is doing the work of A, what about Z? Does he do the work of A+B+C+D ... +Y ?

yes ..

every full node is doing all the work for all block including all transactions ..
that's actually what a blockchain is good for .. it is used to ensure a CONSISTENT set of data among all participants ..

[monsterer]

Surely the only sensible way to determine this is for B to do the exact same work that A did, and arrive at a conclusion?

exactly .. and this is what i usually refer to as "the protocol"

But if B is doing the work of A, what about Z? Does he do the work of A+B+C+D ... +Y ?

[xeroc]

Surely the only sensible way to determine this is for B to do the exact same work that A did, and arrive at a conclusion?

exactly .. and this is what i usually refer to as "the protocol"

basically all transactions that don't do a double spend and are correctly ECC signed are valid .. (no matter the purpose of the transaction) ...

[monsterer]

.. and this will only happen if the transactions of delegate A are valid ..
if delegate A approved transaction that do not fit the protocol .. they are invalidated and not added to the local database of delegate B ..

But how does B know that A's transactions are 'valid'? Surely the only sensible way to determine this is for B to do the exact same work that A did, and arrive at a conclusion?

[xeroc]

- all full nodes match all orders
- a delegate only constructs and transmits a block when due .. no need to construct blocks at any other time

But if that is true, how can delegate B be sure that delegate A's block was valid? Without delegate B producing a synthetic block to check against delegate A's submitted block, there can be no agreement?

delegate B has to update it's local database taking the transactions of delegate A's block into account .. and this will only happen if the transactions of delegate A are valid ..
if delegate A approved transaction that do not fit the protocol .. they are invalidated and not added to the local database of delegate B .. as a consequence .. the block is invalid from delegate B's point of view and is not referenced when he is constructing his block .. hence, delegate A will "miss" his block ..

[monsterer]

- all full nodes match all orders
- a delegate only constructs and transmits a block when due .. no need to construct blocks at any other time

But if that is true, how can delegate B be sure that delegate A's block was valid? Without delegate B producing a synthetic block to check against delegate A's submitted block, there can be no agreement?

[xeroc]

Ok, so all delegates match all orders and produce their own synthetic blocks... which only get submitted when their turn for block production comes around?

- all full nodes match all orders
- a delegate only constructs and transmits a block when due .. no need to construct blocks at any other time

[monsterer]

From my understanding, the delegate is only a delegate when he has to sign his block .. else he is just a full node and does the order matching for the transactions contained in all other blocks continuously ..

Ok, so all delegates match all orders and produce their own synthetic blocks... which only get submitted when their turn for block production comes around?

[xeroc]

I read the link but it didn't cover this.

Thinking out loud here...

My main point is that the orderbook is state which the validity of matched orders depends on directly, but the state of the orderbook depends on the history of the blockchain (as a sequence of replayed operations). Therefore, to match any order with 100% certainty, each delegate would need to replay the entire blockchain in order to rebuild the current orderbook...

...I guess that's actually what they're doing in a continuous and ongoing fashion? They all have a current state, which is the head block plus the mempool, therefore they have the orderbooks. So, to confirm any given order is matched correctly, every delegate must in fact match that order itself to see if it agrees with it's own state? But, since each delegate works on a new block, that means they have to check back and do 51 blocks worth of order matching?

Or am I missing something here?

That's correct.

From my understanding, the delegate is only a delegate when he has to sign his block .. else he is just a full node and does the order matching for the transactions contained in all other blocks continuously ..

For me, the blockchain is a "raw" database .. that database gets updated every 10 secs .. the clients see the updates and construct/update a local database that has the data more structured ..
If you open your ~/.BitShares/chain/index folder you will find the 'index' (nicely structured) databases
while the raw blockchain database is in ~/.BitShares/chain/raw_chain.

All local database indices are updated after receiving a valid block ..
Hence, the client has to have the local database (that is constructed from the blockchain) in order to do order matching

[monsterer]

As long as you follow the 'protocol' you can be sure the orders matched the second the taker's order is confirmed by a single delegate .. (though not with 100% confidence)
You have 100% confidence after 51 delegates the block ..

I read the link but it didn't cover this.

Thinking out loud here...

My main point is that the orderbook is state which the validity of matched orders depends on directly, but the state of the orderbook depends on the history of the blockchain (as a sequence of replayed operations). Therefore, to match any order with 100% certainty, each delegate would need to replay the entire blockchain in order to rebuild the current orderbook...

...I guess that's actually what they're doing in a continuous and ongoing fashion? They all have a current state, which is the head block plus the mempool, therefore they have the orderbooks. So, to confirm any given order is matched correctly, every delegate must in fact match that order itself to see if it agrees with it's own state? But, since each delegate works on a new block, that means they have to check back and do 51 blocks worth of order matching?

Or am I missing something here?

[xeroc]

My point is, how do you get confidence on the validity of the matched orders? Does confidence increase with each block that gets produced, if so, why?

As long as you follow the 'protocol' you can be sure the orders matched the second the taker's order is confirmed by a single delegate .. (though not with 100% confidence)
You have 100% confidence after 51 delegates the block ..

I recommend you
http://wiki.bitshares.org/index.php/FAQs#How_does_DPOS_get_by_with_1_block_recommended_confirmation_versus_BTC.27s_6_block_recommendation.3F

[monsterer]

if the network see an ask in a block .. and a corresponding bid in the next block .. the client figures out that they are matched automatically .. no need to add a transaction to the blockchain for this

My point is, how do you get confidence on the validity of the matched orders? Does confidence increase with each block that gets produced, if so, why?

[xeroc]

there is no "order-matching" transaction ... the order matching is "virtual" (you can see these in your transaction history) .. the blockchain only contains asks and bids .. there's not even a transaction that states 'this order is complete' .. the only other transcation available this "cancel this order" .. that's it ..

if the network see an ask in a block .. and a corresponding bid in the next block .. the client figures out that they are matched automatically .. no need to add a transaction to the blockchain for this

[monsterer]

Bitcoin is supposed to be trustless, but in fact you have to trust the miners, decreasingly so as they produce blocks; each subsequent miner who produces a block, confirms the work of the previous miner. So, at one confirmation you are trusting the miners 100%, at two its 50%, and so on.

In ripple (as I understand it), each ledger is final and cannot be re-orged, so you always have to trust the 'miners' 100%.

Bitshares has the same ever decreasing level of trust as bitcoin for block production, although I'm not entirely clear on whether the DEX means you need to place more trust in the delegates or not (I am ready to be corrected on this). My reasoning is this - since each block contains only transactions, there is no actual orderbook object with which to refer when matching orders, you can only build the OB up over time by processing transactions. This has the implication that, for any given market order in a block, each delegate would need to replay the entire blockchain in order to build the orderbook to process the order. This is impractical, so there must be some work around that delegates use in order to match orders and to confirm that the previous block contains valid matched orders.

Thoughts?