Topic: Next level Bitcoin stress test -- June 29-30 13:00 GMT 2015 - page 3. (Read 16032 times)
I would also like to say thanks for unannounced soft fork of some pools and nodes. Transactions that worked fine 24 hours ago are now rejected by some nodes and miners. The main problem I have with that is that it looks like at lest same of people that are behind this are against announced hard fork. It looks like thanks to this I will have to use my Credit card or cash first time in about 90 days... I just can't get mind funds of a pool... And I see less than half full blocks. So thank you very much for showing me that BTC can be as slow and arbitrary as banks... If a smaller pool operates don't know you will pull this shit that is just great...
20 MB blocks means you need 41 Mbps upload. Most people don't have that even available.
Please share your calculations.
8 peers minimum.
30 seconds maximum to upload new blocks in a timely manner.
160 Mbit * 8 peers / 30 seconds = 42.67 Mbps.
Only if you are miner you need that speed. For normal user you can do that in 5 minutes and you are still more then fine. Miners are connected directly and have bater connection and don't relay on other nodes. And I have second cheapest option at home and it is 10/100 with no limits(none has limits just to be sure). Is internet really that bad in US that this can be an argument that 40 Mbps is so hard to get? But anyway 4Mbps is more then enough at 20 MB
Agreed, my full-node has a time offset of -8 at 4Mbps, so this is not the problem
20 MB blocks means you need 41 Mbps upload. Most people don't have that even available.
Please share your calculations.
8 peers minimum.
30 seconds maximum to upload new blocks in a timely manner.
160 Mbit * 8 peers / 30 seconds = 42.67 Mbps.
Only if you are miner you need that speed. For normal user you can do that in 5 minutes and you are still more then fine. EDIT: "Also who say you will send out to 8 nodes? If you are slower you might send that to only one." Miners are connected directly and have bater connection and don't relay on other nodes. And I have second cheapest option at home and it is 10/100 with no limits(none has limits just to be sure). Is internet really that bad in US that this can be an argument that 40 Mbps is so hard to get? But anyway 4Mbps is more then enough at 20 MB
because this is like waiting 1h for email delivery..
No, your "mail" is delivered. Its just not confirmed yet.uhh ok, so the mail is delivered, but I'm unable to read to content and have to wait unknown time, because lot of guys sending mails.. (btw, yesterday I have to wait 5 hours and 28 minutes for first confirmation)
..if you don't feel this like a problem, believe or not, but it IS problem.
Luke-Jr, you would know better than me, but if I see that there's a transaction on the network which spends coins to an address I control, then I guess you're pointing out that nothing stops me from sending out a transaction signed by that address which sends them elsewhere. Is that right?
But I know none of the wallets I've used allow this ("this will become spendable soon..."). And I'm surprised that a transaction referencing an output which isn't yet confirmed wouldn't be rejected as invalid.
...makes me think that you are just posting this to get paid for your signature ad.
Please see my sig.
Yes, and the coinomat people are starting to get infamous for this.
... or you could look at the current network requirements of a well connected node and see that the supposedly relevant guessing by a certain person further above is just random vague guessing coz he thinks he knows something but doesn't.
A bitcoin with more than 50 connections averages (well) under 40k bytes a second ... total in both directions ... with the current 1Mb block limit.
It gets above that when you let people download the blockchain from you ... ... so you don't do that if it matters ...
So if that 1Mb limit was suddenly 20Mb and you made the unlikely assumption that it would jump up 20 times ...
you're still under 7mbit ... ... ... total in both directions ... on average
So you'd add on top of that your own transactions you are generating ... to get a reasonable idea of the requirements.
It's like guessing that empty blocks solves the problem of a slow crappy getblocktemplate function someone wrote in bitcoind.
No, it's slow crappy pool code and a badly managed pool that's the problem, the slow crappy getblocktemplate function is minor compared to that.
Look at real numbers ...
A bitcoin with more than 50 connections averages (well) under 40k bytes a second ... total in both directions ... with the current 1Mb block limit.
It gets above that when you let people download the blockchain from you ... ... so you don't do that if it matters ...
So if that 1Mb limit was suddenly 20Mb and you made the unlikely assumption that it would jump up 20 times ...
you're still under 7mbit ... ... ... total in both directions ... on average
So you'd add on top of that your own transactions you are generating ... to get a reasonable idea of the requirements.
It's like guessing that empty blocks solves the problem of a slow crappy getblocktemplate function someone wrote in bitcoind.
No, it's slow crappy pool code and a badly managed pool that's the problem, the slow crappy getblocktemplate function is minor compared to that.
Look at real numbers ...
...makes me think that you are just posting this to get paid for your signature ad.
Please see my sig.
jbreher, I hope you will perform a test as well. These are very important, to find weaknesses in BTC companies' implementations, etc
My test was tongue in cheek, motivated by a too-short temper. I've since cooled down.
But my point I think is valid. I think there is a chance this 'test' was motivated by less than altruistic scientific curiosity. I was just pointing out that paying a little more than they were willing to per transaction would likely have resulted in prompt validation.
Here is what I think
https://bitcointalksearch.org/topic/m.11769397
In general no mater how big block tx becomes if Tx fee is low there will be always a chance with little money invested to "spam" the network. A reasonable solution for me is to increase tx fee in a first place then increase max block size if needed
That will be a good step forward to be ready when block reward will be arround zero - a good long term solution which will solve most or all of the current issues
https://bitcointalksearch.org/topic/m.11769397
In general no mater how big block tx becomes if Tx fee is low there will be always a chance with little money invested to "spam" the network. A reasonable solution for me is to increase tx fee in a first place then increase max block size if needed
That will be a good step forward to be ready when block reward will be arround zero - a good long term solution which will solve most or all of the current issues
20 MB blocks means you need 41 Mbps upload. Most people don't have that even available.
Please share your calculations.
8 peers minimum.
30 seconds maximum to upload new blocks in a timely manner.
160 Mbit * 8 peers / 30 seconds = 42.67 Mbps.
If we assume that each transaction received is sent to 2 other nodes, then a full 20 MB block over 10 minutes would mean that you would have needed to send approximately 40 MB during that time.
40 MB X 8 bits per byte = 320 Mbit
There are 600 seconds in 10 minutes.
320 Mbit / 600 seconds = 533,333 kbps
That's only a bit more than half of 1 Mbps.
But you can't spend 10 minutes uploading the block to each peer.40 MB X 8 bits per byte = 320 Mbit
There are 600 seconds in 10 minutes.
320 Mbit / 600 seconds = 533,333 kbps
That's only a bit more than half of 1 Mbps.
Nor will things propagate reasonably if each peer only uploads to one other peer - consider that SPV/light nodes only download.
The network will just break down entirely...
20 MB blocks means you need 41 Mbps upload. Most people don't have that even available.
Please share your calculations.
I'm apparently missing something.
If we assume that each transaction received is sent to 2 other nodes, then a full 20 MB block over 10 minutes would mean that you would have needed to send approximately 40 MB during that time.
40 MB X 8 bits per byte = 320 Mbit
There are 600 seconds in 10 minutes.
320 Mbit / 600 seconds = 533,333 kbps
That's only a bit more than half of 1 Mbps.
Somehow you ended up with a number that is almost 77 times larger than my calculation.
Does that mean you are assuming that each node sends every transaction it receives to 154 other nodes? That doesn't seem like an accurate estimate.
What am I missing?
And aside from that, aren't we looking at 8MB now anyway? The 20MB proposal seems to have been overruled by mining pools. Granted, there's also talk about doubling it every couple of years, but I expect there will be further discourse about that part. Even to someone like me who supports larger blocks, doubling could potentially be a little on the excessive side, but then I guess it all depends on adoption levels.
... and it doesn't matter unless you are mining.
That is only the problem of pools and people using their nodes for solo mining.
Everyone should be running nodes, but most people shouldn't be using them for mining.
That's a risky thing to do ... even some pools do that badly ... like Eligius.
A transaction processing node doesn't need to get every block ASAP.
If it takes even a minute it doesn't matter.
That is only the problem of pools and people using their nodes for solo mining.
Everyone should be running nodes, but most people shouldn't be using them for mining.
That's a risky thing to do ... even some pools do that badly ... like Eligius.
A transaction processing node doesn't need to get every block ASAP.
If it takes even a minute it doesn't matter.
20 MB blocks means you need 41 Mbps upload. Most people don't have that even available.
Please share your calculations.
I'm apparently missing something.
If we assume that each transaction received is sent to 2 other nodes, then a full 20 MB block over 10 minutes would mean that you would have needed to send approximately 40 MB during that time.
40 MB X 8 bits per byte = 320 Mbit
There are 600 seconds in 10 minutes.
320 Mbit / 600 seconds = 533,333 kbps
That's only a bit more than half of 1 Mbps.
Somehow you ended up with a number that is almost 77 times larger than my calculation.
Does that mean you are assuming that each node sends every transaction it receives to 154 other nodes? That doesn't seem like an accurate estimate.
What am I missing?
I got your point, but waiting endless hours for first confirmation (and LOT of services requires at least one confirmation) is imho not comfortable at all and should be somehow changed..
Yes, but all you can do today is ask services to trust your unconfirmed transaction like they do with credit cards.If you defraud them, they can just terminate your service.
If people abuse this in retail, they may end up having to ask for photo id for Bitcoin purchases.
Given a year or so, hopefully Lightning will solve it in a nicer way.
The measurement of full nodes changed.
The measurement by multiple different people happened to all change in just the exact same way so that the same conclusions were drawn? Don't be ridiculous.Furthermore, it is complete bollocks, that you would need a datacenter to have a full node.
20 MB blocks means you need 41 Mbps upload. Most people don't have that even available. Bigger blocks would - for one - make these kinds of attacks more expensive. This stress test is only slightly effecting others because OP is burning coins as fees and miners are - as its intended - greedy. If the max blocksize is 2 MB the same attack would have needed 40 BTC instead of 20 BTC[1] to have the same effect.
Why do you assume the price of a transaction – the txfee – will stay the same as the supply of transaction space increases? This contradicts the law of supply and demand. The price should go down when the supply increases and normal demand stays the same, and the cost of the attack against 2 MB blocks will be exactly the same as the cost of an attack against 1 MB blocks. blocking a tx just because you think it is spam.. is bad.
Bitcoin Core does that.i get the idea of blocking tx's that have values of less than a penny.. but blocking a tx due to data bloat needs careful consideration..
Blocking some kinds of spam is OK, but blocking other kinds of spam is not OK? Avoiding data bloat (UTXO set) is the primary reason for blocking dust. Of course every filter needs careful consideration.Quote
imagine a company wanted to pay its 10,000 staff in bitcoin. and it sent out tx's as such.. luke jr would block the tx.
Congratulations! You just discovered, all by yourself, one of many reasons for why centralization is bad. Keeping the block size small is important to avoid more centralization. Therefore we need to block malicious spam. If Luke mined 100% of all blocks, which he could theoretically do if he got well over 51% of the hashrate, he could block the tx.Quote
the problem is not that tx's need blocking. the problem is that the test is showing that even a small handfull of tx's can cause such controversy. if the blocks were 20mb, there would be no controversy as all tx's would fit happily with no bottleneck..
Now you lost me. Which small handful of tx's caused controversy?If the blocks were larger, blocking transactions will be easier. The number of full nodes has already been reduced by 94% over the last year. If you multiply the resource requirements for running a full node by 20, there won't be many full nodes left. Not running a full node sacrifices both privacy and security. Few full nodes makes it easier to block transactions, because a small set of nodes in a few datacenters are easier to control than a large set spread all over the world.
Furthermore, it is complete bollocks, that you would need a datacenter to have a full node. Please stop spreading that nonsense.
And the 5 blocks before this one was almost empty...
blocking a tx just because you think it is spam.. is bad.
Bitcoin Core does that.i get the idea of blocking tx's that have values of less than a penny.. but blocking a tx due to data bloat needs careful consideration..
Blocking some kinds of spam is OK, but blocking other kinds of spam is not OK? Avoiding data bloat (UTXO set) is the primary reason for blocking dust. Of course every filter needs careful consideration.Quote
imagine a company wanted to pay its 10,000 staff in bitcoin. and it sent out tx's as such.. luke jr would block the tx.
Congratulations! You just discovered, all by yourself, one of many reasons for why centralization is bad. Keeping the block size small is important to avoid more centralization. Therefore we need to block malicious spam. If Luke mined 100% of all blocks, which he could theoretically do if he got well over 51% of the hashrate, he could block the tx.Quote
the problem is not that tx's need blocking. the problem is that the test is showing that even a small handfull of tx's can cause such controversy. if the blocks were 20mb, there would be no controversy as all tx's would fit happily with no bottleneck..
Now you lost me. Which small handful of tx's caused controversy?If the blocks were larger, blocking transactions will be easier. The number of full nodes has already been reduced by 94% over the last year. If you multiply the resource requirements for running a full node by 20, there won't be many full nodes left. Not running a full node sacrifices both privacy and security. Few full nodes makes it easier to block transactions, because a small set of nodes in a few datacenters are easier to control than a large set spread all over the world.
Why are there 3209 Unconfirmed Transactions with 4623.65234375 (KB) backlog. Is this still ongoing?
I don't think so. However there was no blocks mined within the last 30 minutes till the newest block was mined about 3 minutes ago. That block takes 0.39 BTC as transaction fees.
Why are there 3209 Unconfirmed Transactions with 4623.65234375 (KB) backlog. Is this still ongoing?
uhh ok, so the mail is delivered, but I'm unable to read to content and have to wait unknown time, because lot of guys sending mails.. (btw, yesterday I have to wait 5 hours and 28 minutes for first confirmation)
..if you don't feel this like a problem, believe or not, but it IS problem.
More like you can't prove who sent the email for unknown time. Which is actually true, since email is basically always insecure...if you don't feel this like a problem, believe or not, but it IS problem.
A better analogy would be credit card transactions. Those take 6 months to confirm.
yes, but average Joe don't care about 6 months, because he is not waiting during paying process more than 5 hours like me yesterday. He simply don't care about TX's in background between credit company, bank and other institutions and he will literally never find out, that it takes 6 months in "reality"
I got your point, but waiting endless hours for first confirmation (and LOT of services requires at least one confirmation) is imho not comfortable at all and should be somehow changed..
Jump to: