|
Whatever; I've removed Core 0.12 and am now running Classic 0.12. I am unsettled.
|
|
|
|
The full math is here - David you would probably be interested in this if you haven't already seen it. http://www.bitcoinunlimited.info/resources/1txn.pdfThe paper also describes how the sigops attack is mitigated through miners simply mining 1tx blocks whilst validating then pushing that out to other miners whilst they are still validating the 'poison' block. Rational miners will validate the smaller block, and they also be able to mine another block on top of this, orphaning the poison block. The attacker would get one shot, and would quickly be shut out. If you have enough hash rate to be mining blocks yourself its really much more profitable to behave! Thank you so much sgbett; that was a really great read. I must admit I didn't work through all of the math yet but at first blush it appears ok until; The Bitcoin network is naturally limited by block validation and construction times. This puts an upper limit on the network bandwidth of 60KB/sec to transmit the block data to one other peer. Hmm, really? There's no way ever to improve on block validation times? Quantum computers? Nothing? That doesn't ring true. |
|
|
|
|
When I play this out in my mind I see this;
1) eventually SegWit gets out the door and is adopted but if it doesn't reduce verification times then what was the point?
2) even if SegWit does reduce verification times it won't ultimately be enough and a hard limit on sigops will be required
3) the block size limit is adjusted up and up but validation times ultimately dominate the mining process
4) multiple block chain-based applications besides Bitcoin are required to handle the workload in a timely fashion
|
|
|
|
The full math is here - David you would probably be interested in this if you haven't already seen it. http://www.bitcoinunlimited.info/resources/1txn.pdfThe paper also describes how the sigops attack is mitigated through miners simply mining 1tx blocks whilst validating then pushing that out to other miners whilst they are still validating the 'poison' block. Rational miners will validate the smaller block, and they also be able to mine another block on top of this, orphaning the poison block. The attacker would get one shot, and would quickly be shut out. If you have enough hash rate to be mining blocks yourself its really much more profitable to behave! Yummy; thanks. |
|
|
|
This is what BIP109 fixes and why 2 MB hard fork is usefull to be activated as soon as possible. For more info why reducing to 1.3 GB Signature operations in BIP109 2 MB hard fork used by Bitcoin Classic is necessary: http://8btc.com/forum.php?mod=viewthread&tid=29511&page=1#pid374998The worst case block validation costs that I know of for a 2.2 GHz CPU for the status quo, SegWit SF, and the Classic 2 MB HF (BIP109) are as follows (estimated):
1 MB (status quo): 2 minutes 30 seconds (19.1 GB hashed)
1 MB + SegWit: 2 minutes 30 seconds (19.1 GB hashed)
2 MB Classic HF: 10 seconds (1.3 GB hashed)
SegWit makes it possible to create transactions that don't hash a lot of data, but it does not make it impossible to create transactions that do hash a lot of data.
Hmm, the link took me to a whole lot of Asian looking characters; am I meant to use a translator? As such I couldn't find the quoted material. Question: Can the BIP109 magic be applied if we have the 1MB block size limit? If not, why not? |
|
|
|
what are the implications of this "quadratic TX validation" you guys are talking about?
we can't have TX with a huge amount of inputs? or somthing?
Exactly. If/when a transaction comes in with zillions of inputs then everyone verifying it will be subjected to a long computation. of inputs!  this i can understand This is what BIP109 fixes and why 2 MB hard fork is usefull to be activated as soon as possible. For more info why reducing to 1.3 GB Signature operations in BIP109 2 MB hard fork used by Bitcoin Classic is necessary: http://8btc.com/forum.php?mod=viewthread&tid=29511&page=1#pid374998The worst case block validation costs that I know of for a 2.2 GHz CPU for the status quo, SegWit SF, and the Classic 2 MB HF (BIP109) are as follows (estimated):
1 MB (status quo): 2 minutes 30 seconds (19.1 GB hashed)
1 MB + SegWit: 2 minutes 30 seconds (19.1 GB hashed)
2 MB Classic HF: 10 seconds (1.3 GB hashed)
SegWit makes it possible to create transactions that don't hash a lot of data, but it does not make it impossible to create transactions that do hash a lot of data.
Whoa. Hmm, is there a 0.12 version of Classic yet? |
|
|
|
|
Anyone know where someone is tracking average transaction size (# of inputs) over time?
|
|
|
|
|
Naively increasing the block size isn't the be all answer. Sure, when the workload (mempool) is just a bunch of classic small transactions with few inputs then it's great for low fees. But when a transaction comes along with a huge number of inputs (innocent or malevolent) it will clog up the works forcing everyone to perform a long computation to verify it. One of these monsters can ruin your day if the calculation takes a significantly longer than 1 block interval. Or does it? So, we're behind for a little while but then we catch up. Or are we saying there are monsters out there that could take hours or even days to verify?
Is there a tendency over time for transactions to become bushier? When the exchange rate is much larger then the Bitcoin amounts in transaction will tend to be smaller. Does this lead to fragmentation?
|
|
|
|
|
Imagine this; you agree to sell something to someone and they will pay you in Bitcoins. It turns out they have an address with a zillion little outputs in it. So, they go to launch a send to you and find the fee is going to be huge (to cover the cost of all those inputs in a timely fashion). The deal falls through; Bitcoin loses.
Now we can wonder how their address ended up so fragmented but what does it matter? Maybe they were collecting a zillion little drips from faucets. Whatever; they can't spent it like a large output.
|
|
|
|
Oh, I was wrong; get over it, I am.  We can't just add together inputs. Here's an example address https://blockchain.info/unspent?active=1Gx8ivf4xSCqNNtUXQxoyBFd4FeGZvwCHT&format=html with multiple outputs, 7 in this case. To spend the entire lot would involve a transaction with 7 inputs, i.e. not one with just 1 input with the net amount. Bummer. So, then the question is what happened to 19MxhZPumMt9ntfszzCTPmWNQeh6j6QqP2 that it had so many tiny outputs in it? Still the owner could have created multiple smaller transactions instead of one large one. |
|
|
|
that is the key
i say keep it simple stupid
if it has more than a zillion it's not getting included.
You and I think very much alike. Lauda, can you point us at a really big but totally legit/non-abusive transaction? |
|
|
|
Luada, again we owe you a debt of gratitude. You do the work the rest of us are too lazy to do. Now I am beginning to understand why the verification process scales quadratic; not that me understanding matters per se but it is nice to know.
Example of such transaction a can be seen here (from last year). Holy cow! now does this constitute a legitimate TX? can't we just ignore this type of TX? Depends; sorry. In a sense it is absolutely legit; it follows all of the rules. But it easily could have been coded less abusively. Let's first look at a much more classic transaction https://blockchain.info/tx/3a6a7d2456bfd6816ee1164e7c11307fa1c6855ee3116b6a1f8e6a14a98b04c4;address (amount) 12kDK8snhBD6waJ2NaMB7QvSf4DzMcE9ad (0.21963496 BTC - Output) {call it what you want; this is an input} 1FmUPrnZTBymMT3ktgMx61hQ3JRyWD7NPY - (Unspent) 0.14193496 BTC 13dhrUuUe2MrZsufYGAZnwnyE7k97FRZ1v - (Unspent) 0.0776 BTC Nice and easy; one input, two outputs; classic. Now compare that to the big one; 19MxhZPumMt9ntfszzCTPmWNQeh6j6QqP2 (Brainwallet - dog) (0.00001 BTC - Output) 19MxhZPumMt9ntfszzCTPmWNQeh6j6QqP2 (Brainwallet - dog) (0.00001 BTC - Output) ... 19MxhZPumMt9ntfszzCTPmWNQeh6j6QqP2 (Brainwallet - dog) (0.00001 BTC - Output) {this is the 1598 occurrence} ... {followed by zillions of more inputs} This could have been codes as; 19MxhZPumMt9ntfszzCTPmWNQeh6j6QqP2 (Brainwallet - dog) (0.01598 BTC - Output) ... and saved 1597 inputs on this batch of inputs alone. Ok, sure, we could ignore this one; um, need to figure out how to recognize such without rejecting non-abusive transactions. |
|
|
|
Luada, again we owe you a debt of gratitude. You do the work the rest of us are too lazy to do. Now I am beginning to understand why the verification process scales quadratic; not that me understanding matters per se but it is nice to know.
Example of such transaction a can be seen here (from last year). Holy cow! |
|
|
|
what are the implications of this "quadratic TX validation" you guys are talking about?
we can't have TX with a huge amount of inputs? or somthing?
Exactly. If/when a transaction comes in with zillions of inputs then everyone verifying it will be subjected to a long computation. |
|
|
|
and libsecp256k1 offers 5x validation speeds.
Okay, I've asked around on IRC and got this: in order to sign or verify the tx, each input has to construct a special version of the tx and hash it. so if there are n inputs there are nxn hashes to be done. hence quadratic scaling.
the TLDR I believe is: ecdsa operations are the most computationally expensive part of verifying transactions, for normal, small size transactions, but they scale linearly with the size (number of inputs).whereas if a transaction in current bitcoin has tons of inputs, the bottleneck moves over to the hashing/preparing data to to be signed, because that time depends on the *square* of the number of inputs.
so usually it's ultra small, but it blows up for large N inputs.
Why doesn't libsecp256k1 have an effect on this? because libsecp256k1 is an ECC library so it's only the "ecdsa" part in the above.
Hopefully this helps, albeit I doubt that many are going to understand it. It certainly isn't easy. Luada, again we owe you a debt of gratitude. You do the work the rest of us are too lazy to do. Now I am beginning to understand why the verification process scales quadratic; not that me understanding matters per se but it is nice to know. |
|
|
|
ill yield to your 2309
Outstanding. Thank you; I could not ask for more. |
|
|
|
a fee of 5¢/transaction isn't so burdensome, is it?
5¢ makes things like mixing coins expensive and suddenly anything less then 5$ TX is not as fun to do also its not so much the cost that bothers me its the fact that it make newbies lives harder. we never use to have " My TX is taking forever to confrim " threads before, and i wish they would go away. lets not forget that ~90% of TX on the network today are low value... i would assume the 5¢ fee is already prohibiting all kinds of legit TX that would otherwise take place on the blockchain. Couldn't agree more. As long as we are careful about the signature verification scaling issue, and the releasing multiple features around the same time issue, and improving the wallet software to include a big enough fee to get transactions through in a timely fashion; I'm all for it. My personal proposal would be to check on the progress of SegWit (give us the real story here). If it is indeed really ready for primetime in April then, fine, roll with it. If there's any chance of slipping then delay it until it is soup and in the meantime, put out a very simple block increase *with* a check to reject transactions with more than some limit of signatures/inputs. Those needing to push through work with more inputs can split their work into multiple transactions. Either way, I'll be happy. Both ways should see the normal fees drop to earlier levels, reducing the pain/anxiety. |
|
|
|
if 1000 has 33% increase=1333
2000 =2666
Yes, of course, you are correct, allowing for rounding, increasing 1000 by 33% is 1000 + 1000 * 33% = 1333 and increasing 2000 by 33% is 2000 + 200 * 33% = 2666. Hmm, I'll try to explain; 1200MHz - 900Mhz = 300MHz 300Mhz / 900MHz = 33% -- so we say we have increased the processor frequency by 33%. Also, 900MHz / 1200MHz = 75% -- so we say instructions will take only 75% as long to run. So, for a fixed amount of work, we can calculate how long it will take to run. If a 2000 sigop transaction takes t amount of time on the 900MHz processor then we expect it to only take 0.75t on the faster one. There are potential hazards in this assertion. The software might not be strictly compute bound. Also, not every instruction will necessarily get the same advantage from the speedup, e.g. branches, etc. *But* this does not indicate how much faster more work will run unless the software scales linearly with frequency. If the software does indeed scale linearly then the amount of time it takes to get a fix amount of work done will decrease linearly and the amount of work that can get done in the same amount of time will increase linearly. For some unexplained (to me yet) reason, signature verification does not scale linearly. Instead it scales as the square; | 1 | 1 | | 2 | 4 | | 3 | 9 | | 4 | 16 | | 5 | 25 | | ... | ... | | n | n² | | ... | ... |
So, yes, one signature verification could indeed get done in 0.75t but 2000 will take 2000²*(0.75t). Gosh, I am terribly sorry if I haven't explained this well. |
|
|
|
|
Show Posts
