Topic: Gold collapsing. Bitcoin UP. - page 85. (Read 2032247 times)

your willingness to connect two dots is astounding

Validation time, in its self is not an issue, miners have approximately 10 minus to validate, the issues is not the time, it's that you can hack the protocol and validate nothing or force your competitor to waste time validating to gain an advantage, (this is also a temporary hack and if anything highlights where development should occur)

Propagation time is a feature not an issue, (a symbiotic byproduct) that adds to the incentives that make bitcoin work.

their are hypothetical issues with how these features could be abused, the problem is the developers are not separating the hypothetical issues form the features, and working on that, some are working to to change the features.    

Yeah... maybe you need to read this again. What did I tell you about putting words in people's mouth.

"A bear on Bitcoin"  So much non sense!

Greg has made it abundantly clear that he is a Bear on Bitcoin.  he should step down as a core dev.

and what's this about him not thinking Bitcoin can be used on small devices?  smartphones are KEY to Bitcoin's long term success.

 

Are you really trying to spin this one again?

i find it amusing that you bash Satoshi on the one hand but when you find a morsel quote of his (which you've misread) you latch onto it as gospel.

if you read the actual link you posted, Satoshi was talking about how Bitcoin should not be combined with BitDNS.  he's not even talking about tx's.  he wanted them to be separate with their own fates.  he also drew an extreme example of how BitDNS might want to include other huge datasets while Bitcoin might want to keep it small as an example of how the decision making might diverge btwn the two.  not that Bitcoin users wanted to keep a small blockchain.

anyone concerned about the BTC lower high?

Hearn #rekt confirmed:


 

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009727.html

Greg's reply.

This is entertaining 

Thanks for the update! The effect on transaction validation time should be essentially the same, though... it should be enough to make 'overly complicated' blocks impossible for the time being.

he's backed off the 100kB tx limit in deference to limiting the #sigops and simplifying the hashing process.  for details, someone provide the link to his ML post.

b/c i'm assuming it would be cost prohibitive for you?  and pretty much anyone else i might add altho i'm sure you'd argue not for a gvt; which actually might be true which is why i advocate NO LIMIT as that would throw a huge amount of uncertainty as to just how successfully one could jack the mempool in that scenario as it removes user disruption and thus greatly increases the financial risk ANY attacker would be subject o.


i know; your normal sized convoluted multi-input block that would have to, btw, be constructed as a non-standard tx block that is self mined by a miner which makes it unlikely b/c you'd have to believe a miner would be willing to risk his reputation and financial viability by attacking the network in such a way which has repercussions. that's also good news in that it removes a regular spammer or gvt attacker (non-miner) from doing this. and finally, that type of normal sized but convoluted validation block will propagate VERY slowly which risks orphaning which makes that attack also unlikely.

Bloating Layer 1 is a complicated solution; scaling at Level 2+ is an elegant one.

You still don't understand Tannenbaum's maxim.  Its point isn't 'keep software simple FOREVER NO MATTER WHAT.'  That is your flawed simpleton's interpretation.

"Fighting features" means ensuring a positive trade-off in terms of security and reliability, instead of carelessly and recklessly heaping on additional functionality without the benefit of an adversarial process which tests their quality and overall impact.

One does not simply "remove the artificial cap."  You may have noticed some degree of controversy in regard to that proposal.  Bitcoin is designed to strenuously resist (IE fight) hard forks.  Perhaps you were thinking of WishGrantingUnicornCoin, which leaps into action the moment anyone has an idea and complies with their ingenious plan for whatever feature or change they desire.

Like DoS, CVE-2013-2292, as an issue that exists now, is fairly successfully mitigated by the 1MB cap.  It is not a separate concern because larger blocks exacerbate the problem in a superlinear manner.  You don't get to advocate 8MB blocks, but then wave your hands around eschewing responsibility when confronted with the immediate entailment of purposefully constructed 8MB tx taking 64 times longer to process than a 1MB one.  The issue is intrinsic to larger blocks, which is why Gavin proposed a 100k max tx size be married to any block size increase.

Fully parsed, what you are claiming is


Do you realize how naive that makes you look?

I believe Gavin wants to limit TXN size to 100kiB at the same time the bigger block hard fork comes into effect. Shouldn't this very much remove your worries about an increase in blocksize?

And, yes, I agree, faster validation is even better than putting another artificial limit into the code base.

Why would you doubt it?

But in your example of 20MB, there are much easier and cheaper ways to DoS the network, as mentioned.

so looking at the peak of the last attack ~40BTC per day worth of tx fees were harvested.  let's say we go to 20MB blocks tomorrow.  since real tx's only amount to ~500kB per block worth of data, you'd have to essentially fill the 20MB all by yourself and spend 20*40BTC=800BTC per day give or take.  at $290/BTC that would equal $232000 per day.  and then you'd have to sustain that to even dent the network; say for a month.  that would cost you $7,000,000 for one month.  you sure you can do that all by yourself?

Yes

More "attacks" please.

Just not really big blocks yet.

1-3mb are ok.  8mb is too much right now (yes the miners are wrong, there's bad stuff they haven't seen yet).
Getting blocks that take >10mins to validate is not a good thing.

Fortunately with better code optimization, we may get that validation time down even more, as well as the other advances to make this safer.

We'll get there.

Well, no.
Bigger blocks just make the "attacks" marginally more expensive.  
Individually, I could also swamp the mempool at any of the proposed sizes.

The "attacks" are providing some funding, so I don't really mind them all that much.  This tragedy of the commons is not quite so tragic as the UTXO set growth and chain size would be with a similar attack on larger blocks, especially if combined with a validation time attack (TX with many inputs and outputs in a tangled array).
Very large blocks would be a much more vulnerable environment in which to conduct such an attack.  We'll get to the point of ameliorating these vulnerabilities, and the right people are working on it.

Patience...  Bitcoin is still in beta, its so young.  Lets give it the chance to grow up without breaking it along the way.

notice how the extra fees paid by full blocks actually strengthened the mining hashrate during the last attacks.  probably the extra revenue from tx fees encouraged miners to bring on more hashrate.  that's a good thing and could actually be even better if they were allowed to harvest/clear all the additional fees in the bloated mempools:

clearing out the mempool quickly would solidify the attackers losses and gratify the previous tx validation work already done by all full nodes in the network.