Author Topic: Blockchain trust requirement - bitcoin vs ripple vs bitshares  (Read 3856 times)

0 Members and 1 Guest are viewing this topic.

Offline 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.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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

  • Guest
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.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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 ..

Offline 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 ?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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) ...

Offline 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?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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 ..

Offline 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?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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

Offline 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?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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

Offline 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?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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

Offline 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?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads