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?
Nodes validate & store all transactions of every block added to the chain. If that is not the case then it is not Bitcoin. maybe you misunderstood. in the 'relay only' mode being hypothesized by Adam, the blocks are never fully broadcast, only the transaction headers or something. If a transaction was referenced but wasn't in the nodes mempool it would have to be fetched. ....  |
|
|
|
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?
Nodes validate & store all transactions of every block added to the chain. If that is not the case then it is not Bitcoin. is it true miners have all the recent TX's in there mempool and when they get a new block they receive those same TX's all over again with the newblock? is this a little redundant? maybe we can broadcast only the transaction headers or something.
That is what the relay network does but once the headers are broadcasted the miners still need to fully validate it before starting mining a new block on top. Again, this has absolutely no impact on the full nodes that are not mining and need to receive, validate and store full blocks. |
|
|
|
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?
Nodes validate & store all transactions of every block added to the chain. If that is not the case then it is not Bitcoin. |
|
|
|
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. |
|
|
|
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.) 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. |
|
|
|
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. |
|
|
|
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  |
|
|
|
Hey guys, does anybody have any news from Montreal? Did anything interesting happen or been decided?
Please share this info here if you have any. I have been very busy this weekend so I couldn't watch the live broadcast or listen to it on the YouTube. I am very interested by this and can't find anything.
Thanks!
Nothing was decided but it was a fantastic opportunity for the industry, developers and miners to share concerns and ideas about Bitcoin moving forward. Coindesk has a good article on the first day here: http://www.coindesk.com/scaling-bitcoin-day-1-constructive-debate-shines/You can find transcripts of most of the discussion here: http://diyhpl.us/wiki/transcripts/scalingbitcoin/Most of the slides used by presenters: https://www.dropbox.com/sh/xrnpadhhee26482/AAD1UYgVDXgYByGe4FnqIWBka?dl=0My highlights: - Ittay Eyal's tests and models - Bram Cohen's talk on fees handling - Miles Carlsten's work on the "mining gap" - All of sunday morning sessions on payment channels and layer 2 as well as mining & network costs Overall it was a great experience and I had a really good time. |
|
|
|
Strange, it's steady ?
Memory and bandwidth are limited, of course, at some point we would get steady numbers, just like water can't be heated above 100C in normal conditions. That's why a block size limit is not required to get a fee market. In a world of spherical cows maybe, yes maybe |
|
|
|
AFAIK the keys are not only held by three people. They are held by more, but I'm not sure if that information is public. I would not mind Andreas having a key. If we were to give access to this information to someone, then Andreas would be a great candidate (if not the best).
Off topic: A lot of people probably don't like him for various reasons. I think that he is in the group of handful people that know almost everything (impossible) about Bitcoin.
I am quite convinced this is absolutely wrong. He's made a couple of head scratching comments over the years. |
|
|
|
what are Andreas credentials? breaking blockchain.info? posting btc stealing malware on twitter? |
|
|
|
|
Peter R managed to fit XT shilling & blockstream trolling in his presentation. Amateurish at best
|
|
|
|
A fee market already exists and will exist with or without a block size limit:
hey peter do you even exist? WHO ARE YOU? If you're still wondering about this, my talk at the conference is in about a half hour. You can watch it on the livestream. Hope you enjoy it! Edit: Oops. I was rushing to post this during the break and logged into the wrong account! wtf!? Regardless of anyone's definition of validity, one chain will be longer than the rest (it will contain more cumulative work). I am betting that this (longest) chain will contain a block greater than 1 MB in size by this time next year.
There is no ambiguity in that definition.
While I'm not on Peter R's side in the XT debate, he's correct about this. The terms of this potential "bet" are clear. In any case, even if there were some ambiguity, that's one reason there's a neutral third party in a 2-of-3 multisig. Now for something completely different. Consider this modified version of "the bet": Peter R and anti-Peter R each put 1 BTC into a 2-of-3 multisig with a neutral third party. One year from now, the 2 BTC are paid out to Peter R on every chain that has had a block over 1MB. The 2 BTC are paid out to anti-Peter R on every chain that has not had a block over 1MB. This would actually give people a way to trade potential coins on potential multiple forks before the potential forks actually occur. It's a little surprising there aren't services offering something like this, given how adamant many people on different sides seem to be. |
|
|
|
|
Matt Corallo just pointed out at the conference that propagation has little to do w/ bandwidth connectivity but general tcp packet loss which can occurs regardless of your connectivity.
I know there is some posts on the dev list referencing this. Don't ask me to explain in details this is a bit beyond me technically
|
|
|
|
Has anyone ever talked about compressing the blocks?
Dunno... What about using pointers? The question would be where do you store the stuff pointed to? there's already some miners that use a method of compressing blocks. The p2p protocol presently only supports propagation of solved blocks in full; i.e., blocks are not compressed.
However, the Corallo Relay Network does support a sort of compression. Rather than transmitting all the transactions in a solved blocks, since most the other miners know about them already, it just transmits indices that refer to each transaction (sort of like a map for how the TXs fit in the block). Greg Maxwell claims that the Corallo Relay Network attains a coding gain of about 250 (1 MB is compressed to about 4 kilobytes); however, I believe it is less in practice.
Techniques like invertible bloom lookup tables (IBLTs) could also be used to compress solved blocks in the future; Rusty Russell is presently researching this possibility.
That's not compression. your right, but still its 250 times faster then sending out the whole block the network could be optimized further by compressing each TX's before sending it out on the network might not get much coding gain trying to "zip" TX its just ~300 very random bytes All of this doesn't avoid the necessity for the network to handle the full weight of these blocks. It's a transmission method and nothing more. agreed what we don't agree on is what is an expectable max weight for a block i think its close to 500MB maybe 1GB Do you figure you're smarter than everyone or that all of us are retarded? No one agree on any size but certainly you're the only coming up with that type of numbers. Maybe you'd like to consider you simply don't understand the issue well enough? |
|
|
|
Has anyone ever talked about compressing the blocks?
Dunno... What about using pointers? The question would be where do you store the stuff pointed to? there's already some miners that use a method of compressing blocks. The p2p protocol presently only supports propagation of solved blocks in full; i.e., blocks are not compressed.
However, the Corallo Relay Network does support a sort of compression. Rather than transmitting all the transactions in a solved blocks, since most the other miners know about them already, it just transmits indices that refer to each transaction (sort of like a map for how the TXs fit in the block). Greg Maxwell claims that the Corallo Relay Network attains a coding gain of about 250 (1 MB is compressed to about 4 kilobytes); however, I believe it is less in practice.
Techniques like invertible bloom lookup tables (IBLTs) could also be used to compress solved blocks in the future; Rusty Russell is presently researching this possibility.
That's not compression. your right, but still its 250 times faster then sending out the whole block the network could be optimized further by compressing each TX's before sending it out on the network might not get much coding gain trying to "zip" TX its just ~300 very random bytes All of this doesn't avoid the necessity for the network to handle the full weight of these blocks. It's a transmission method and nothing more. |
|
|
|
|
Show Posts
