Scaling Bitcoin Above 3 Million TX pre block

[sAt0sHiFanClub]

@sAt0sHiFanClub, I don't know your definition of a transaction, but if we take the Lightning Network as an example, it does increase transaction throughput without neccessarily increasing the blocksize limit. Large blocks is not the only way of increasing throughput.

Your going off on a tangent now. LN is paperware at the moment. Lets stick to bitcoin for now, eh?

So your definition of a transaction only includes on-chain transactions, then your statement is correct. My definition also includes trustless off-chain transactions (one way of scaling Bitcoin), and under that definition mine is correct.

Oh, we really have to be precise...

I think you have reflected your point through the nearest axis, and then continued into another domain entirely.

[RoadTrain]

@sAt0sHiFanClub, I don't know your definition of a transaction, but if we take the Lightning Network as an example, it does increase transaction throughput without neccessarily increasing the blocksize limit. Large blocks is not the only way of increasing throughput.

Your going off on a tangent now. LN is paperware at the moment. Lets stick to bitcoin for now, eh?

So your definition of a transaction only includes on-chain transactions, then your statement is correct. My definition also includes trustless off-chain transactions (one way of scaling Bitcoin), and under that definition mine is correct.

Oh, we really have to be precise...

I think you have reflected your point through the nearest axis, and then continued into another domain entirely.

You are being overly cryptic here, I'm not an English native, so if you want me to answer, please rephrase.

[jonald_fyookball]

@sAt0sHiFanClub, I don't know your definition of a transaction, but if we take the Lightning Network as an example, it does increase transaction throughput without neccessarily increasing the blocksize limit. Large blocks is not the only way of increasing throughput.

Your going off on a tangent now. LN is paperware at the moment. Lets stick to bitcoin for now, eh?

So your definition of a transaction only includes on-chain transactions, then your statement is correct. My definition also includes trustless off-chain transactions (one way of scaling Bitcoin), and under that definition mine is correct.

Oh, we really have to be precise...

How is LN trustless?

[RoadTrain]

@sAt0sHiFanClub, I don't know your definition of a transaction, but if we take the Lightning Network as an example, it does increase transaction throughput without neccessarily increasing the blocksize limit. Large blocks is not the only way of increasing throughput.

Your going off on a tangent now. LN is paperware at the moment. Lets stick to bitcoin for now, eh?

So your definition of a transaction only includes on-chain transactions, then your statement is correct. My definition also includes trustless off-chain transactions (one way of scaling Bitcoin), and under that definition mine is correct.

Oh, we really have to be precise...

How is LN trustless?

If Bitcoin transactions can be signed with a new sighash type that addresses malleability,
these transfers may occur between untrusted parties along the transfer route by contracts which, in the event of uncooperative or hostile
participants, are enforceable via broadcast over the bitcoin blockchain
in the event of uncooperative or hostile participants, through a series
of decrementing timelocks.

[sAt0sHiFanClub]

How is LN trustless?

If Bitcoin transactions can be signed with a new sighash type that addresses malleability,
these transfers may occur between untrusted parties along the transfer route by contracts which, in the event of uncooperative or hostile
participants, are enforceable via broadcast over the bitcoin blockchain
in the event of uncooperative or hostile participants, through a series
of decrementing timelocks.

The piece you quoted relates to bitcoin transactions if we introduce new sighash functionality, they are not a unique property of LN.  This will require an enormous development effort as its complex to achieve workable contracts without malleability.  Sighash signing types allow for changes to the tx before they are final. But even when final, malleability still persists no matter how it was signed. Thats why most of this functionality was removed from bitcoin.

LN as it would be workable now assumes a certain level of trust LN Presentation, slide 31

● If Carol refuses to disclose R, she will hold
up the channel between Alice and Bob
○ If her channel expires after Alice and Bob’s she can
steal funds by redeeming the hashlock!
● Bob has to be rich for this to really work
3rd party low-trust multisig and/or extremely
small values sent can mostly work today

[RoadTrain]

How is LN trustless?

If Bitcoin transactions can be signed with a new sighash type that addresses malleability,
these transfers may occur between untrusted parties along the transfer route by contracts which, in the event of uncooperative or hostile
participants, are enforceable via broadcast over the bitcoin blockchain
in the event of uncooperative or hostile participants, through a series
of decrementing timelocks.

The piece you quoted relates to bitcoin transactions if we introduce new sighash functionality, they are not a unique property of LN.  This will require an enormous development effort as its complex to achieve workable contracts without malleability.  Sighash signing types allow for changes to the tx before they are final. But even when final, malleability still persists no matter how it was signed. Thats why most of this functionality was removed from bitcoin.

LN as it would be workable now assumes a certain level of trust LN Presentation, slide 31

● If Carol refuses to disclose R, she will hold
up the channel between Alice and Bob
○ If her channel expires after Alice and Bob’s she can
steal funds by redeeming the hashlock!
● Bob has to be rich for this to really work
3rd party low-trust multisig and/or extremely
small values sent can mostly work today

I don't see how it's relevant. Of course, for LN to actually work at its best, we have to do some adjustments to the Bitcoin protocol. I didn't state we don't have to. All of this is stated in the paper explicitly.

[adamstgBit]

Any thing you compress has to be uncompressed on each node to be confirmed before it can be propagated out to the next node.
This would slow propagation with the current block size.

The whole point of Corallo has nothing to do with compression - it is to do with nodes already being aware of txs so blocks can just use txid's rather than the actual tx content.

It is simply saving bandwidth in terms of information that was already communicated.

The current @adamstgBit forum member seems to be completely unaware of this and thinks that some magic "compression" has been invented (am pretty sure the old @adamstgBit would have known better which makes it more likely that this account has been sold to a newbie).

yes i know it's not technically compression, that doesn't  change the fact that this magical magic makes sending a block 250times faster....
it's all about bandwidth and this saves 250X more bandwidth, how is this not exciting?
using this method all miners need to do is keep up with TPS so there mempool is in sync with all other miners
which makes it alot easier to handle huge blocks.

[adamstgBit]

I'm having trouble following this.

"But one of the central pillars of smallblockism is that having larger blocks will result in increased orphan rates as the larger blocks take longer to propagate across the network.  But Matts relay network, if applied to bitcoin as a whole rather than a select cadre of approved players, could deliver a performance increase that would obviate that argument."

Doesn't the entire block need to be sent somewhere (at least from a miner to one of the nodes in the relay network)?
 

A block is a (header + n(tx)) The vast majority of the transactions should already be in the nodes mempool, so why do they have to be sent a second time? Obviously due to the nature of the network, not all nodes will have the exact same set of tx'x, but any missing ones can be requested. Also, the relay keeps track of what tx's have been sent.

This is one of the long time conundrums of bitcoin - the redundant resending of transactions. You get a series of 10 byte ids instead of ~250b transactions.

Ok assuming the miner only sends a condensed version of the block with pointers to the relay network, the relay network still has to broadcast the full block then to other nodes, correct?

Correct - while the relay backbone remains a separate network, then yes. (but not over the relay network - they get propagated over the vanilla p2p as far as i know)  But I can imagine a case where it could be extended to a wider network.

Well then as much as I don't like to agree with the small blockers, their argument is correct that orphan rates will increase since the full block needs at some point to be broadcast.   Although as I pointed out to Adam, would need to be much bigger (60mb) before this is a problem with current Internet speeds.

the full block is never sent, miners accumulate TX's as they come in, one of the functions of the relay network is to relay those TX fast, but when it's time to send out a new block every miner has all the TXs in the meme pool, so this condensed version of the block ( god forbid i call it compressed ) this is all anyone really needs.

As long as miners can keep up with the TX's as they come in and by doing so keep all their mem pools in sync ( it doesn't have to be perfectly sync...) a full block never needs to be broadcast.

This method will reduce orphan rates due to slow block propagation, miners ( the smart ones) currently use the relay network for exactly that purpose, they are able to get the new block 250X faster and this gives them an edge.

edit: wait ya you're right, because this isn't a standard way of sending out block the relay network learns of the new block by receiving the block in full. and then relays the condensed version of the block. but whatever this could idea can make smallblockist argument that having larger blocks will result in increased orphan, no longer true. which is a big step in the right direction IMO.

[jonald_fyookball]

I'm having trouble following this.

"But one of the central pillars of smallblockism is that having larger blocks will result in increased orphan rates as the larger blocks take longer to propagate across the network.  But Matts relay network, if applied to bitcoin as a whole rather than a select cadre of approved players, could deliver a performance increase that would obviate that argument."

Doesn't the entire block need to be sent somewhere (at least from a miner to one of the nodes in the relay network)?
 

A block is a (header + n(tx)) The vast majority of the transactions should already be in the nodes mempool, so why do they have to be sent a second time? Obviously due to the nature of the network, not all nodes will have the exact same set of tx'x, but any missing ones can be requested. Also, the relay keeps track of what tx's have been sent.

This is one of the long time conundrums of bitcoin - the redundant resending of transactions. You get a series of 10 byte ids instead of ~250b transactions.

Ok assuming the miner only sends a condensed version of the block with pointers to the relay network, the relay network still has to broadcast the full block then to other nodes, correct?

Correct - while the relay backbone remains a separate network, then yes. (but not over the relay network - they get propagated over the vanilla p2p as far as i know)  But I can imagine a case where it could be extended to a wider network.

Well then as much as I don't like to agree with the small blockers, their argument is correct that orphan rates will increase since the full block needs at some point to be broadcast.   Although as I pointed out to Adam, would need to be much bigger (60mb) before this is a problem with current Internet speeds.

the full block is never sent, miners accumulate TX's as they come in, one of the functions of the relay network is to relay those TX fast, but when it's time to send out a new block every miner has all the TXs in the meme pool, so this condensed version of the block ( god forbid i call it compressed ) this is all anyone really needs.

As long as miners can keep up with the TX's as they come in and by doing so keep all their mem pools in sync ( it doesn't have to be perfectly sync...) a full block never needs to be broadcast.

This method will reduce orphan rates due to slow block propagation, miners ( the smart ones) currently use the relay network for exactly that purpose, they are able to get the new block 250X faster and this gives them an edge.

I think you don't know what you're talking about, (although I don't know the technical details well enough to prove it.)

[brg444]

I'm having trouble following this.

"But one of the central pillars of smallblockism is that having larger blocks will result in increased orphan rates as the larger blocks take longer to propagate across the network.  But Matts relay network, if applied to bitcoin as a whole rather than a select cadre of approved players, could deliver a performance increase that would obviate that argument."

Doesn't the entire block need to be sent somewhere (at least from a miner to one of the nodes in the relay network)?
 

A block is a (header + n(tx)) The vast majority of the transactions should already be in the nodes mempool, so why do they have to be sent a second time? Obviously due to the nature of the network, not all nodes will have the exact same set of tx'x, but any missing ones can be requested. Also, the relay keeps track of what tx's have been sent.

This is one of the long time conundrums of bitcoin - the redundant resending of transactions. You get a series of 10 byte ids instead of ~250b transactions.

Ok assuming the miner only sends a condensed version of the block with pointers to the relay network, the relay network still has to broadcast the full block then to other nodes, correct?

Correct - while the relay backbone remains a separate network, then yes. (but not over the relay network - they get propagated over the vanilla p2p as far as i know)  But I can imagine a case where it could be extended to a wider network.

Well then as much as I don't like to agree with the small blockers, their argument is correct that orphan rates will increase since the full block needs at some point to be broadcast.   Although as I pointed out to Adam, would need to be much bigger (60mb) before this is a problem with current Internet speeds.

the full block is never sent, miners accumulate TX's as they come in, one of the functions of the relay network is to relay those TX fast, but when it's time to send out a new block every miner has all the TXs in the meme pool, so this condensed version of the block ( god forbid i call it compressed ) this is all anyone really needs.

As long as miners can keep up with the TX's as they come in and by doing so keep all their mem pools in sync ( it doesn't have to be perfectly sync...) a full block never needs to be broadcast.

This method will reduce orphan rates due to slow block propagation, miners ( the smart ones) currently use the relay network for exactly that purpose, they are able to get the new block 250X faster and this gives them an edge.

Here, some homework material:

http://diyhpl.us/wiki/transcripts/scalingbitcoin/

Come back when you've read and understood most of this  

[adamstgBit]

I'm having trouble following this.

"But one of the central pillars of smallblockism is that having larger blocks will result in increased orphan rates as the larger blocks take longer to propagate across the network.  But Matts relay network, if applied to bitcoin as a whole rather than a select cadre of approved players, could deliver a performance increase that would obviate that argument."

Doesn't the entire block need to be sent somewhere (at least from a miner to one of the nodes in the relay network)?
 

A block is a (header + n(tx)) The vast majority of the transactions should already be in the nodes mempool, so why do they have to be sent a second time? Obviously due to the nature of the network, not all nodes will have the exact same set of tx'x, but any missing ones can be requested. Also, the relay keeps track of what tx's have been sent.

This is one of the long time conundrums of bitcoin - the redundant resending of transactions. You get a series of 10 byte ids instead of ~250b transactions.

Ok assuming the miner only sends a condensed version of the block with pointers to the relay network, the relay network still has to broadcast the full block then to other nodes, correct?

Correct - while the relay backbone remains a separate network, then yes. (but not over the relay network - they get propagated over the vanilla p2p as far as i know)  But I can imagine a case where it could be extended to a wider network.

Well then as much as I don't like to agree with the small blockers, their argument is correct that orphan rates will increase since the full block needs at some point to be broadcast.   Although as I pointed out to Adam, would need to be much bigger (60mb) before this is a problem with current Internet speeds.

the full block is never sent, miners accumulate TX's as they come in, one of the functions of the relay network is to relay those TX fast, but when it's time to send out a new block every miner has all the TXs in the meme pool, so this condensed version of the block ( god forbid i call it compressed ) this is all anyone really needs.

As long as miners can keep up with the TX's as they come in and by doing so keep all their mem pools in sync ( it doesn't have to be perfectly sync...) a full block never needs to be broadcast.

This method will reduce orphan rates due to slow block propagation, miners ( the smart ones) currently use the relay network for exactly that purpose, they are able to get the new block 250X faster and this gives them an edge.

Here, some homework material:

http://diyhpl.us/wiki/transcripts/scalingbitcoin/

Come back when you've read and understood most of this  

[brg444]

I'm having trouble following this.

"But one of the central pillars of smallblockism is that having larger blocks will result in increased orphan rates as the larger blocks take longer to propagate across the network.  But Matts relay network, if applied to bitcoin as a whole rather than a select cadre of approved players, could deliver a performance increase that would obviate that argument."

Doesn't the entire block need to be sent somewhere (at least from a miner to one of the nodes in the relay network)?
 

A block is a (header + n(tx)) The vast majority of the transactions should already be in the nodes mempool, so why do they have to be sent a second time? Obviously due to the nature of the network, not all nodes will have the exact same set of tx'x, but any missing ones can be requested. Also, the relay keeps track of what tx's have been sent.

This is one of the long time conundrums of bitcoin - the redundant resending of transactions. You get a series of 10 byte ids instead of ~250b transactions.

Ok assuming the miner only sends a condensed version of the block with pointers to the relay network, the relay network still has to broadcast the full block then to other nodes, correct?

Correct - while the relay backbone remains a separate network, then yes. (but not over the relay network - they get propagated over the vanilla p2p as far as i know)  But I can imagine a case where it could be extended to a wider network.

Well then as much as I don't like to agree with the small blockers, their argument is correct that orphan rates will increase since the full block needs at some point to be broadcast.   Although as I pointed out to Adam, would need to be much bigger (60mb) before this is a problem with current Internet speeds.

the full block is never sent, miners accumulate TX's as they come in, one of the functions of the relay network is to relay those TX fast, but when it's time to send out a new block every miner has all the TXs in the meme pool, so this condensed version of the block ( god forbid i call it compressed ) this is all anyone really needs.

As long as miners can keep up with the TX's as they come in and by doing so keep all their mem pools in sync ( it doesn't have to be perfectly sync...) a full block never needs to be broadcast.

This method will reduce orphan rates due to slow block propagation, miners ( the smart ones) currently use the relay network for exactly that purpose, they are able to get the new block 250X faster and this gives them an edge.

I think you don't know what you're talking about, (although I don't know the technical details well enough to prove it.)

You are correct. The full block is broadcasted to full nodes and validated in full by all of them.

[adamstgBit]

I'm having trouble following this.

"But one of the central pillars of smallblockism is that having larger blocks will result in increased orphan rates as the larger blocks take longer to propagate across the network.  But Matts relay network, if applied to bitcoin as a whole rather than a select cadre of approved players, could deliver a performance increase that would obviate that argument."

Doesn't the entire block need to be sent somewhere (at least from a miner to one of the nodes in the relay network)?
 

A block is a (header + n(tx)) The vast majority of the transactions should already be in the nodes mempool, so why do they have to be sent a second time? Obviously due to the nature of the network, not all nodes will have the exact same set of tx'x, but any missing ones can be requested. Also, the relay keeps track of what tx's have been sent.

This is one of the long time conundrums of bitcoin - the redundant resending of transactions. You get a series of 10 byte ids instead of ~250b transactions.

Ok assuming the miner only sends a condensed version of the block with pointers to the relay network, the relay network still has to broadcast the full block then to other nodes, correct?

Correct - while the relay backbone remains a separate network, then yes. (but not over the relay network - they get propagated over the vanilla p2p as far as i know)  But I can imagine a case where it could be extended to a wider network.

Well then as much as I don't like to agree with the small blockers, their argument is correct that orphan rates will increase since the full block needs at some point to be broadcast.   Although as I pointed out to Adam, would need to be much bigger (60mb) before this is a problem with current Internet speeds.

the full block is never sent, miners accumulate TX's as they come in, one of the functions of the relay network is to relay those TX fast, but when it's time to send out a new block every miner has all the TXs in the meme pool, so this condensed version of the block ( god forbid i call it compressed ) this is all anyone really needs.

As long as miners can keep up with the TX's as they come in and by doing so keep all their mem pools in sync ( it doesn't have to be perfectly sync...) a full block never needs to be broadcast.

This method will reduce orphan rates due to slow block propagation, miners ( the smart ones) currently use the relay network for exactly that purpose, they are able to get the new block 250X faster and this gives them an edge.

I think you don't know what you're talking about, (although I don't know the technical details well enough to prove it.)

 you're right, because this isn't a standard way of sending out block the relay network learns of the new block by receiving the block in full. and then relays the condensed version of the block. but whatever it could easily be THE WAY ( at which point there will never be a need to send out the whole block) and this could idea can make smallblockist argument that having larger blocks will result in increased orphaned blocks, no longer true. which is a big step in the right direction IMO.

[adamstgBit]

it be gr8 if someone that is more knowledgeable then me, back me on this...

wheres Peter?

[jonald_fyookball]

I'm having trouble following this.

"But one of the central pillars of smallblockism is that having larger blocks will result in increased orphan rates as the larger blocks take longer to propagate across the network.  But Matts relay network, if applied to bitcoin as a whole rather than a select cadre of approved players, could deliver a performance increase that would obviate that argument."

Doesn't the entire block need to be sent somewhere (at least from a miner to one of the nodes in the relay network)?
 

A block is a (header + n(tx)) The vast majority of the transactions should already be in the nodes mempool, so why do they have to be sent a second time? Obviously due to the nature of the network, not all nodes will have the exact same set of tx'x, but any missing ones can be requested. Also, the relay keeps track of what tx's have been sent.

This is one of the long time conundrums of bitcoin - the redundant resending of transactions. You get a series of 10 byte ids instead of ~250b transactions.

Ok assuming the miner only sends a condensed version of the block with pointers to the relay network, the relay network still has to broadcast the full block then to other nodes, correct?

Correct - while the relay backbone remains a separate network, then yes. (but not over the relay network - they get propagated over the vanilla p2p as far as i know)  But I can imagine a case where it could be extended to a wider network.

Well then as much as I don't like to agree with the small blockers, their argument is correct that orphan rates will increase since the full block needs at some point to be broadcast.   Although as I pointed out to Adam, would need to be much bigger (60mb) before this is a problem with current Internet speeds.

the full block is never sent, miners accumulate TX's as they come in, one of the functions of the relay network is to relay those TX fast, but when it's time to send out a new block every miner has all the TXs in the meme pool, so this condensed version of the block ( god forbid i call it compressed ) this is all anyone really needs.

As long as miners can keep up with the TX's as they come in and by doing so keep all their mem pools in sync ( it doesn't have to be perfectly sync...) a full block never needs to be broadcast.

This method will reduce orphan rates due to slow block propagation, miners ( the smart ones) currently use the relay network for exactly that purpose, they are able to get the new block 250X faster and this gives them an edge.

I think you don't know what you're talking about, (although I don't know the technical details well enough to prove it.)

 you're right, because this isn't a standard way of sending out block the relay network learns of the new block by receiving the block in full. and then relays the condensed version of the block. but whatever it could easily be THE WAY ( at which point there will never be a need to send out the whole block) and this could idea can make smallblockist argument that having larger blocks will result in increased orphaned blocks, no longer true. which is a big step in the right direction IMO.

Makes sense in theory.

[brg444]

I'm having trouble following this.

"But one of the central pillars of smallblockism is that having larger blocks will result in increased orphan rates as the larger blocks take longer to propagate across the network.  But Matts relay network, if applied to bitcoin as a whole rather than a select cadre of approved players, could deliver a performance increase that would obviate that argument."

Doesn't the entire block need to be sent somewhere (at least from a miner to one of the nodes in the relay network)?
 

A block is a (header + n(tx)) The vast majority of the transactions should already be in the nodes mempool, so why do they have to be sent a second time? Obviously due to the nature of the network, not all nodes will have the exact same set of tx'x, but any missing ones can be requested. Also, the relay keeps track of what tx's have been sent.

This is one of the long time conundrums of bitcoin - the redundant resending of transactions. You get a series of 10 byte ids instead of ~250b transactions.

Ok assuming the miner only sends a condensed version of the block with pointers to the relay network, the relay network still has to broadcast the full block then to other nodes, correct?

Correct - while the relay backbone remains a separate network, then yes. (but not over the relay network - they get propagated over the vanilla p2p as far as i know)  But I can imagine a case where it could be extended to a wider network.

Well then as much as I don't like to agree with the small blockers, their argument is correct that orphan rates will increase since the full block needs at some point to be broadcast.   Although as I pointed out to Adam, would need to be much bigger (60mb) before this is a problem with current Internet speeds.

the full block is never sent, miners accumulate TX's as they come in, one of the functions of the relay network is to relay those TX fast, but when it's time to send out a new block every miner has all the TXs in the meme pool, so this condensed version of the block ( god forbid i call it compressed ) this is all anyone really needs.

As long as miners can keep up with the TX's as they come in and by doing so keep all their mem pools in sync ( it doesn't have to be perfectly sync...) a full block never needs to be broadcast.

This method will reduce orphan rates due to slow block propagation, miners ( the smart ones) currently use the relay network for exactly that purpose, they are able to get the new block 250X faster and this gives them an edge.

I think you don't know what you're talking about, (although I don't know the technical details well enough to prove it.)

you're right, because this isn't a standard way of sending out block the relay network learns of the new block by receiving the block in full. and then relays the condensed version of the block. but whatever it could easily be THE WAY ( at which point there will never be a need to send out the whole block) and this could idea can make smallblockist argument that having larger blocks will result in increased orphaned blocks, no longer true. which is a big step in the right direction IMO.

No. You are confused.

The relay network serves as a more efficient messaging route for the miners. The nodes have nothing to do with it. Once the chain moves forward with a new block  every nodes needs to be validate it in full.

Moreover the relay network is currently used by a great majority of the large miners and especially those in China for example that have historically experienced orphan concerns. Unfortunately this is seemingly not enough for some of them who choose to do SPV mining so as to even more mitigate their risks of mining orphans.

[adamstgBit]

@brg444

here's a similar idea

http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/

[brg444]

@brg444

here's a similar idea

http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/

I'm sorry but it is obvious you don't understand how Bitcoin works. I'd like to tell it another way but at this point I won't be wasting my efforts until you correct these fundamental misunderstandings on your own.

[jonald_fyookball]

Well, I think one problem with only sending pointers is what happens when a node doesn't have a particular transaction?  How does it get it?

[adamstgBit]

Well, I think one problem with only sending pointers is what happens when a node doesn't have a particular transaction?  How does it get it?

would just ask around for the ones it's missing

it would be interesting to know exactly how insync a node from chain and one from US are