Bitcoin Forum
February 22, 2020, 01:55:29 PM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: 10x scaleup & Stable TPS: new blocks carry hashes of TXs, no TXs themself ??  (Read 147 times)
jiapw
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
February 10, 2019, 08:47:02 PM
 #1

What if:
a newly mined block is broadcast with only hashes of confirmed TXs, instead of TXs themselves?

Motivation:
broadcast new block is on the critical path of chain growth and fork resolution. We should minimize the propagation time.
TX are going beyond transfer. DApp’s TX can be large, and thus significantly lower the TPS

Assumption:
most TX in the block should have been broadcast, and already stay in the mempool of every full nodes and miners. (need to be verified quantitatively). We don’t need to transfer them again when they are confirmed and embedded in the new blocks.


Pros:
1. nearly 10x bandwidth saving for pure coin transfer. (~300 bytes/tx  --->  32 bytes/tx), even more for TX of DApps.
2. lower bandwidth consumption means less propagation time of the new block in the entire network.
3. less propagation time means lower orphan rate, or more rooms for enlarging block size or reducing creation interval.

4. TX size will then be unrelated with block size. Block can always carry a certain number of transactions. TPS will then be stable.

5. On-the-fly generation of transaction by the current miner will be discouraged because it will lower the acceptance probability. (others needs more time to verify)
6. No modification to current data structure, a block of TX-hashes can be verified by the merkle tree root in the block header as well.
7. No modification to existing procedures like transaction verification, bootstrapping, history archiving etc. A full node received block-of-TX-hashes should assemble the block-of-TX (a structure as before) based on block-of-TX-hashes then go forward.

Cons:
1. requires a new syntax in the protocol, so that a full node is able to request a TX by its hash from immediate upstream peer (who broadcast the block to me).
2. requires a new type of data structure: a block of TX-hashes.
3. Miner may bias to pick up old transactions (more likely stay in other's mempool)




... Or, maybe Bitcoin network is working in this way already??


Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
aliashraf
Hero Member
*****
Offline Offline

Activity: 994
Merit: 727

always remember the cause


View Profile WWW
February 11, 2019, 12:45:26 AM
Merited by bones261 (2), gmaxwell (1), ETFbitcoin (1)
 #2


... Or, maybe Bitcoin network is working in this way already??

Actually it does! Since compact blocks and bip 152 bitcoin is doing what you have proposed above, somehow. Take a look at this FAQ: https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2968
Merit: 3262



View Profile
February 11, 2019, 01:48:19 AM
Merited by bones261 (3), ETFbitcoin (1)
 #3

1. nearly 10x bandwidth saving for pure coin transfer. (~300 bytes/tx  --->  32 bytes/tx),
The transactions need to be sent regardless, so the improvement from this kind of change using your tx size as an example is 600 bytes to 300 bytes (assuming somehow no bytes were used to send the transaction). So an asymptotic 2x improvement in terms of bandwidth usage, at most.

As aliashraf notes, the bitcoin protocol already does something similar to what you imagine but about 5.3x more efficient (6 bytes/tx instead of 32).  Even more efficient is possible, but there is diminishing returns for increased complexity.  ... Going from 306 bytes/tx to closer to 300 isn't terribly interesting from a bandwidth usage perspective.
jiapw
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
February 11, 2019, 05:53:42 AM
 #4


Actually it does! Since compact blocks and bip 152 bitcoin is doing what you have proposed above, somehow. Take a look at this FAQ: https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/

Thanks !!  have this been implemented and activated in latest client?
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2968
Merit: 3262



View Profile
February 11, 2019, 10:51:06 AM
Last edit: February 11, 2019, 11:16:32 AM by gmaxwell
Merited by bones261 (2), ETFbitcoin (1), aliashraf (1)
 #5

[Edit: Sorry for the slightly screwed up thread history, I accidentally hit [edit] instead of quote and killed jiapw's reply to me. I believe all or almost all of it is in the quotes in my reply.]

No, it is more than that.
Yes, which is why I said "from a bandwidth usage perspective".

There are other considerations, of course. Your post appeared to be comparing the savings from a bandwidth usage perspective so I responded on those terms.

If you want to talk about latency-- I don't believe serialization delay was ever the largest bottleneck.  Historically round trips and hop by hop validation were the biggest sources of latency.  Fibre protocol eliminates round trips completely, and since forwarding processeds ahead of validation (except for hash consistency) there is relatively little hop-by-hop validation delay anymore, at least in the last year and a half or so.

Since your understanding is years behind the state of the art... Perhaps you should spend a bit more time researching before commencing with the lecturing? :-/

Quote
While broadcasting unconfirmed transaction is not on the critical path. It is in low priority, and can be delayed without affecting chain growth.
That isn't precisely correct. Yes, unconfirmed transaction relay is off the critical path for block propagation, but once a transaction is in a block it must be received and processed at or before that time and can no longer be delayed.  If it hasn't already been received and processed, then it is back on the critical path and so it cannot be arbitrarily delayed without impact.  The worst case propagation is also very important-- especially due to selfish mining, and in that case no transactions are known ahead of the block.

have this been implemented and activated in latest client?
It was implemented in Bitcoin Core almost three years ago. And related techniques (using a two byte index into a buffer of most-recently relayed transactions) were used in the fast-block-relay-protocol several (2-ish?) years before that. Without them Bitcoin would be in a sad state today.
jiapw
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
February 11, 2019, 07:35:57 PM
 #6

There are other considerations, of course. Your post appeared to be comparing the savings from a bandwidth usage perspective so I responded on those terms.

If you want to talk about latency-- I don't believe serialization delay was ever the largest bottleneck.  Historically round trips and hop by hop validation were the biggest sources of latency.  Fibre protocol eliminates round trips completely, and since forwarding processeds ahead of validation (except for hash consistency) there is relatively little hop-by-hop validation delay anymore, at least in the last year and a half or so.

Since your understanding is years behind the state of the art... Perhaps you should spend a bit more time researching before commencing with the lecturing? :-/

Trying to catch up with my common sense with networking.  Grin   latency is about bandwidth. Propagation latency is the sum of many thing in each hop: [round trip] + [data size/bandwidth] + [block validation time]. For bitcoin with 1MB, you are right since [data size/bandwidth] is not the dominate factor. But for BCH with 8MB block or even more,  [data size/bandwidth] will be the major factor in the latency.

Quote
That isn't precisely correct. Yes, unconfirmed transaction relay is off the critical path for block propagation, but once a transaction is in a block it must be received and processed at or before that time and can no longer be delayed.  If it hasn't already been received and processed, then it is back on the critical path and so it cannot be arbitrarily delayed without impact.  The worst case propagation is also very important-- especially due to selfish mining, and in that case no transactions are known ahead of the block.

That's true. But if a TX is not sufficiently propagated, miner will less likely picked it up as well. broadcasting of TX is pipelined, it don't hurt throughput much if everyone is delayed. But creating of new blocks are not pipelined, any delay of broadcasting of new blocks will result in higher fork rate, and force you to make block size smaller or enlarge the creation interval.

Quote
It was implemented in Bitcoin Core almost three years ago. And related techniques (using a two byte index into a buffer of most-recently relayed transactions) were used in the fast-block-relay-protocol several (2-ish?) years before that. Without them Bitcoin would be in a sad state today.

Thanks for letting me know. Is there a list of what BIP is accepted, and what BIP is ready implemented ?
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!