Thanks to people who support 1-2 MB blocks - great idea u fools...

[adamstgBit]

but i have a hard time believing downloading ~1MB about every 10mins is making your internet notably slower.

It isn't that simple Adam. I'm supposed to share this information (along with the rest of the block chain) with my peers. That's the point of the peer to peer network. With default settings my node sends (not even including data received) hundreds of gigabytes per month. I have to limit connections to less than a fifth of default to keep my internet functioning at a point where no one in the household complains. Again, I have modern computers with multi core processors and top tier home internet speeds.

Maybe I'm just unlucky and someone out there is using my node to re-download the entire chain every other day!

Let's see some improvements in QoS (in the Bitcoin software itself) without me needing to be a network admin before we just takes the training wheels off, ehh?

maybe i should fire up Bitcoin0.11.0 and see how it feels these days.

Run it for just a month with near 100% uptime, then get back to me.

all kinds of improvements should be made... there should be different levels of "full nodes" obviously someone might want to only realy TX to a few peers and someone else might want to be a "SuperNode" connecting to 100's of peers.

this is going to take a while to sycn up i'm over a year behind. 

Isn't the point of pruned node?

a pruned  node can't be used as a wallet
it can reduce the storage size of the blockchain to MB's
but you end up with a full node without a wallet, it verifies and relays TX and that's all it does.
i really don't get why you can't have both a wallet and prune your blockchain

[1714637907]

1714637907

[1714637907]

1714637907

[1714637907]

1714637907

[johnyj]

I'm more interested in this



30 seconds to verify a transaction on one node! And to relay that block to all nodes you need at least 4-5 hop, that adds up to 2-3 minutes, I believe that we are going to see some serious problem when we reach the 2MB block size limit (If it ever get that large)

Actually I'm getting more cautious after more evidence showing that the blockchain does not scale at current technology, not even to 2MB if you want to have some safety margin

[adamstgBit]

              

quit your trolling johnyj

also links to videos would be better than screen caps

[RealBitcoin]

Well well well, the morons that say that >1 MB blocks will destroy the network, are you living in a cave with 1 kilobyte internet bandwidth?



Guys what the fuck are you talking about? I alone can forward the entire bitcoin network capacity/bandwidth, seriously we live in the 2015 where internet speed is not a scarce resource anymore.

Fuck your XT , fuck the forks, just raise the fucking block size limit already!

[johnyj]

             

quit your trolling johnyj

also links to videos would be better than screen caps

Link is in the top of this thread, time in the screenshot is clear

[tl121]

I'm more interested in this

30 seconds to verify a transaction on one node! And to relay that block to all nodes you need at least 4-5 hop, that adds up to 2-3 minutes, I believe that we are going to see some serious problem when we reach the 2MB block size limit (If it ever get that large)

Actually I'm getting more cautious after more evidence showing that the blockchain does not scale at current technology, not even to 2MB if you want to have some safety margin

If the slide is correct and Core actually takes O(N^2) to verify a block then the software has a serious performance bug.  There is no excuse for this.  If this is true it calls into question the competence and credibility of the core developers.  I would have expected better from "experts" with PhD degrees in Computer Science who are supposed to be operating in the real world of product development.

It would be interesting to hear what the Core developers have to say about this issue. (And other developers who are working on alternate code bases.)

 (My apologies if this report proves false.)

[johnyj]

I'm more interested in this

30 seconds to verify a transaction on one node! And to relay that block to all nodes you need at least 4-5 hop, that adds up to 2-3 minutes, I believe that we are going to see some serious problem when we reach the 2MB block size limit (If it ever get that large)

Actually I'm getting more cautious after more evidence showing that the blockchain does not scale at current technology, not even to 2MB if you want to have some safety margin

If the slide is correct and Core actually takes O(N^2) to verify a block then the software has a serious performance bug.  There is no excuse for this.  If this is true it calls into question the competence and credibility of the core developers.  I would have expected better from "experts" with PhD degrees in Computer Science who are supposed to be operating in the real world of product development.

It would be interesting to hear what the Core developers have to say about this issue. (And other developers who are working on alternate code bases.)

 (My apologies if this report proves false.)

This is a nature result of how bitcoin works. For validation of each transaction, you must validate all of its unspent output all the way down to its root, when the unspent output are all dust coming from thousands of other dusts and dusts several layers down, the time to validate the transaction rises exponentially

Just try to import a private key from coinwallet give out and see how long it takes on your machine to get an idea why 1MB block can even be deadly sometimes
https://bitcointalk.org/index.php?topic=1175321.msg12390644#msg12390644

[jonald_fyookball]

if Peter R is correct with his free market hypothesis, then your concern johnnyj is a moot point because miners won't broadcast blocks that take hours to confirm.  Pretty simple concept don't you think?

[johnyj]

if Peter R is correct with his free market hypothesis, then your concern johnnyj is a moot point because miners won't broadcast blocks that take hours to confirm.  Pretty simple concept don't you think?

IMO, supply/demand curve in a free market exists only on books of economy schools, it never really happens in reality because the reality is magnitudes complex than this too simplified model. I have pointed several weaknesses in his modeling

https://bitcointalk.org/index.php?topic=1179712.msg12417772#msg12417772

Back to the topic, Mark also said the nodes can limit maximum size of transaction to reduce the relay chance of such transaction. However, this 1MB transaction was intentionally made by F2pool to sweep the dust in those addresses (they contain more than 0.5 btc). And what if someone put 5 BTC in those dust addresses? Then every miner will try to include this mega transaction and cause the network to hiccup. So it only takes 5 BTC to disturb the bitcoin network if every miner is just aiming for the best economic interest

[adamstgBit]

if Peter R is correct with his free market hypothesis, then your concern johnnyj is a moot point because miners won't broadcast blocks that take hours to confirm.  Pretty simple concept don't you think?

IMO, supply/demand curve in a free market exists only on books of economy schools, it never really happens in reality because the reality is magnitudes complex than this too simplified model. I have pointed several weaknesses in his modeling

https://bitcointalk.org/index.php?topic=1179712.msg12417772#msg12417772

Back to the topic, Mark also said the nodes can limit maximum size of transaction to reduce the relay chance of such transaction. However, this 1MB transaction was intentionally made by F2pool to sweep the dust in those addresses (they contain more than 0.5 btc). And what if someone put 5 BTC in those dust addresses? Then every miner will try to include this mega transaction and cause the network to hiccup. So it only takes 5 BTC to disturb the bitcoin network if every miner is just aiming for the best economic interest

its not a question of supply and demand, if miners know other miners will orphan his block if it take >a few seconds to validate then no reward is worth getting your block orphan cuz you don't get a reward if your block is orphaned.

i guess miners have to come up with some guide lines as to what constitutes a valid block, or more to the point what constitutes an invalid block.

pretty sure it would be really easy to get all miners to agree a block that takes 1hour to validate is invalid.
at the same time i wonder how hard it would be for them to agree on no more then 2 seconds  validation time....

[jonald_fyookball]

if Peter R is correct with his free market hypothesis, then your concern johnnyj is a moot point because miners won't broadcast blocks that take hours to confirm.  Pretty simple concept don't you think?

IMO, supply/demand curve in a free market exists only on books of economy schools, it never really happens in reality because the reality is magnitudes complex than this too simplified model. I have pointed several weaknesses in his modeling

https://bitcointalk.org/index.php?topic=1179712.msg12417772#msg12417772

Back to the topic, Mark also said the nodes can limit maximum size of transaction to reduce the relay chance of such transaction. However, this 1MB transaction was intentionally made by F2pool to sweep the dust in those addresses (they contain more than 0.5 btc). And what if someone put 5 BTC in those dust addresses? Then every miner will try to include this mega transaction and cause the network to hiccup. So it only takes 5 BTC to disturb the bitcoin network if every miner is just aiming for the best economic interest

Well, forgive me for posting cross thread, but your argument that Peter's modelling isn't valid
because different miners have different configurations doesn't really seem like a strong argument.

If some miners don't want to do it (create a big block), they can, and if others won't, they won't.
Still don't see why we need a block cap to enforce what miners will do.

[johnyj]

its not a question of supply and demand, if miners know other miners will orphan his block if it take >a few seconds to validate then no reward is worth getting your block orphan cuz you don't get a reward if your block is orphaned.

i guess miners have to come up with some guide lines as to what constitutes a valid block, or more to the point what constitutes an invalid block.

Partly true, if all the miners have an agreement that refuse to relay a block that takes bigger than a few seconds to validate. However, some of the super nodes might have 10 times more capacity that can verify it 10 times faster. And F2pool does not need other miners to relay his blocks, he just need to mine continuously two blocks in a row to write his block permanently into the blockchain, it happens quite often https://www.blocktrail.com/BTC

[johnyj]

If some miners don't want to do it (create a big block), they can, and if others won't, they won't.
Still don't see why we need a block cap to enforce what miners will do.

Those so called rational human in economy books are like animals,  they only care about the profit. In reality human have more visions. Many miners build mining farms not for profit from mining blocks, but for constructing the infrastructure of a global independent financial universe, and there are many aspects have much more weight than the fee from a block (that's the reason the difficulty does not drop when it takes more money to mine bitcoin than its market price). Being agile and robust is always preferred

[jonald_fyookball]

Those so called rational human in economy books are like animals,  they only care about the profit. 

Yeah, thats the point.

If a block takes too long, probability rises that another miner will find solve the block first.
So they won't do it.

[RoadTrain]

Those so called rational human in economy books are like animals,  they only care about the profit. 

Yeah, thats the point.

If a block takes too long, probability rises that another miner will find solve the block first.
So they won't do it.

On the other hand, the July hardfork has shown us that miners don't necessarily validate blocks before mining on top of them -- the so-called SPV-mining.
Suppose only Chinese (the majority of hashrate) are doing SPV-mining. It means that they are very quickly noticing each others blocks, and start mining on top of them without waiting for validation. In this case, the rest of the miners will experience increased orphan rates, because they are wasting hases while waiting for validation. Of course, they can start SPV-mining as well, but I don't know where it gets us.

[Peter R]

Those so called rational human in economy books are like animals,  they only care about the profit.  

Yeah, thats the point.

If a block takes too long, probability rises that another miner will find solve the block first.
So they won't do it.

On the other hand, the July hardfork has shown us that miners don't necessarily validate blocks before mining on top of them -- the so-called SPV-mining.
Suppose only Chinese (the majority of hashrate) are doing SPV-mining. It means that they are very quickly noticing each others blocks, and start mining on top of them without waiting for validation. In this case, the rest of the miners will experience increased orphan rates, because they are wasting hases while waiting for validation. Of course, they can start SPV-mining as well, but I don't know where it gets us.

If some miners are SPV mining they will still orphan blocks that take along time to propagate.  Imagine an SPV miner receives the block header for a BIG block and, while he is still receiving that block's contents, he fully receives and validates another smaller block.  He would then switch to the smaller block that came later because he is 100% sure that it is correct (and less than 100% sure that the large block is correct).  

[Peter R]

if Peter R is correct with his free market hypothesis, then your concern johnnyj is a moot point because miners won't broadcast blocks that take hours to confirm.  Pretty simple concept don't you think?

IMO, supply/demand curve in a free market exists only on books of economy schools, it never really happens in reality because the reality is magnitudes complex than this too simplified model.

Are you saying that the Laws of Supply and Demand are not useful?

I have pointed several weaknesses in his modeling

https://bitcointalk.org/index.php?topic=1179712.msg12417772#msg12417772

I agree with your point that each miner will have his own values of the network propagation impedance and latency (my paper mentions this too).  But that doesn't affect the existence of the fee market.  

[LiteCoinGuy]

I'm more interested in this



30 seconds to verify a transaction on one node! And to relay that block to all nodes you need at least 4-5 hop, that adds up to 2-3 minutes, I believe that we are going to see some serious problem when we reach the 2MB block size limit (If it ever get that large)

Actually I'm getting more cautious after more evidence showing that the blockchain does not scale at current technology, not even to 2MB if you want to have some safety margin

as i can see it you can have 3,2 MB blocks today without a problem. and with some tweaks you can go even higher as he said too.

[coalitionfor8mb]

Do those of you arguing for a removal (or increase in size) of the 1 mb anti-spam limit even run a full node? (Adam, it's pretty clear from your comments that you most certainly do not.)

Has the spam problem been solved? Including all the spam in the permanent record that we (those of us who care about decentralization) all have to maintain forever isn't a solution.

I've been running a full node for several years now. I used to argue how easy it was. It used to be something I was comfortable doing with my daily use computer. At some point, I had to switch to dedicated hardware because of the resources the software was using. Then I had to limit the maximum amount of connections to my node because it was eating so much bandwidth that I couldn't even surf the web properly (hundreds of gigabytes per month). I have modern computers with lots of RAM and fast SSDs. My internet speeds are some of the fastest available for home users. Yet, running a Bitcoin node is no longer something I would consider "easy". This is all with the 1mb anti-spam measure in place!

Are you seriously going to try and convince me that an 8x increase in block size limit is no big deal? I'm sure if you build it, they will come. If the limit is increased, transactions will increase (that's what this thread is suggesting after all). More transactions and larger blocks will significantly affect how easy (or difficult) it is to run a full node. I'm a Bitcoin enthusiast. I've been somewhat of a Bitcoin cheerleader for years now. I'm certain that if we simply increase the amount of information that needs to be shared on the p2p network, I will no longer be able to effectively run a full node.

If a Bitcoin enthusiast like myself is questioning my ability to effectively run a full node in the face of increasing block sizes, you can bet your ass that is going to have an impact on decentralization.

You can go ahead and call that nonsense if you want.

A small correction to what otherwise seems like a very reasonable argument.

The static limit in question cannot serve as a "spam filter", because only individual mining nodes decide on what gets into the block and what doesn't. The line between "spam" and "legitimate" transactions here is very thin (if not non-existent). But the limit does indeed define an overall "bandwidth target" for the network, which in turn determines its potential size (what many don't realize in these discussions is that bigger blocks are definitely possible today, but only in a smaller tightly connected network, which means that home users no longer decide on consensus rules and with that all we know and value about Bitcoin might begin shifting rapidly). If Bitcoin loses its mass (represented by its home-based demographic) it will simply fly away.  

Now, with that in mind, we need to understand that rising the limit linearly may cause the actual bandwidth in the network to grow exponentially, due to peers sending the same data again and again multiple times. So, we have to approach this responsibly, which means that any scaling plans beyond the next 4-6 years must be considered too risky and therefore rejected.

...
30 seconds to verify a transaction on one node! And to relay that block to all nodes you need at least 4-5 hop, that adds up to 2-3 minutes, I believe that we are going to see some serious problem when we reach the 2MB block size limit (If it ever get that large)

Actually I'm getting more cautious after more evidence showing that the blockchain does not scale at current technology, not even to 2MB if you want to have some safety margin

Although an example above looks like an edge-case, we definitely need to keep those in mind as potential attack vectors.

Regarding scaling at current technology levels, while I myself haven't had any difficulties syncing up and running a full node (with current limit) for multiple days in a row, I haven't run it for longer periods of time to see if it bumps into any bandwidth related issues (I've been planning on running a node continuously after a computer upgrade anyways).

So, a proper testing would be required for the whole ecosystem with an aim to run full nodes at home for at least a month (in oder to test ISP-related bandwidth caps as well) at near full capacity with our new projected desired hard limit in place before we can whole-heartedly commit to deploy it in production. I guess, the second part of the workshops (scheduled for year's end) was intended to do just that.

[Soros Shorts]

I am glad that we are finally past "it is just downloading 8MB every 10 minutes, morons".

Every reasonable Bitcoiner wants the benefits of bigger blocks, but not at the expense of not being able to run a full node at home.

BTW, it currently costs $60 a month to run a full node on a dedicated Microsoft Azure VM. This includes virtual hardware (includes 1 dedicated CPU core) and bandwidth, which is around 600GB a month (mostly outgoing). It is not quite "free" anymore.