Topic: What is still driving the enthusiasm of bitcoins over other currencies? (Read 3188 times)

+1


We could always do both: try to build consensus for shortening Bitcoin's block time, and educate people on the real advantages and disadvantages of a shorter block time, to dispel the hype about it.

One thing that I'd suggest be kept in mind is that some things are intrinsically easy to market and hype, and a shorter block time might be one of them, so even if the advantages are cosmetic, it would still benefit Bitcoin to adopt it.

That kind of analysis would be interesting. I look forward to read about it.

first mover advantage and none of the new currencies have a single killer feature that makes them rediculously better then.  Take PPCoin which is my preferred alternative.  All sorts of great features but the major drawback that for right now the majority of coins that have been mined so far were mined first day.  Needs time to mature to be competitive or beat out btc.

Ah yes, that's right.  I actually deleted that post shortly after posting it because I noticed this for a second, but the brain fart won out in the end and I reposted it without fixing it   I should've just written it down explicitly like you did.

This formula is a first approximation, where it is assumed that miners rarely end up working on competing chains.  As we lower T while keeping x fixed, we can intuitively see that the likelihood of races between miners increases, i.e. higher order terms in the orphan rate become important.  As you mentioned, this is due to network delays.  It's during these races that hashing power is wasted, so T should be set high enough to keep their frequency low.

I'll try and come up with the next order term for the orphan rate.  This will be from the cases where another miner finds a block at roughly the same time as our miner, and gets it to some portion of the miners before our miner gets his block to them.

Sure it would be "beneficial" to lower it to the "optimal" value, but practically speaking it's probably just cosmetic.  If the problem is people misunderstanding the issue, then perhaps educating people is the better solution.

Good formula.
Let's extend our analysis a bit.
Let "x" be transaction rate, i.e. number of transactions per second. And "t0" - average transaction validation time, i.e. block validation time divided by number of transactions in that block, in the first approximation we can assume that "t0" doesn't depend on block size.

Than, number of transactions to be validated N = x*T
and time required for validation t = x*T*t0

Thus, orphans rate, expressed with theese variables: 1 - e^(-x*t0). We see, in first approximation it doesn't depend on T. Dependacy on T arises from network delays.

I agree, that working on payment channels is important. But may be it would be beneficial for Bitcoin to adopt shorter block times. At least it definitely would eliminate that marketing issue.

Both of these statements are false.

The only objective definition of "better" that can be applied to this situation is the one that more closely matches the needs of the customers.

In both cases, the market preferred Windows 95 and VHS. It is true that Betamax produced superior picture quality, but VHS had a longer recording time. The aggregated preferences of all the individuals buying video recording machines (the market) rated recording time as being more important than picture quality, therefore they chose VHS.

VHS was better. To assert otherwise means that one would need to discover some principle by which their individual preferences could be transformed into a universal principle that everybody else must adhere to regardless of their own, possibly differing, individual preferences.

No I think I have a pretty good idea. Your explanation glosses over the nuances of DDoS, which in summary attempts to overload the resources available to an online service provider. DDoS is a progression from DoS (denial of service) which began as an attack on early websites with methods as simple as rapid requests. The defense was then to filter problematic IPs, which led to the attack becoming "distributed" where problem IP traffic blended with legitimate traffic. Complex sites, like heavily database driven ones (like MtGox for example), could be quickly overwhelmed.

Such DDoS, which is what I believe MtGox fell victim to, while more effective is generally less available because attackers must control a range of IP traffic. This is why I mentioned motivation and profitability being factors for DDoS. What I consider the most severe form of DDoS is what you refer to, where an attacker has access to such a large footprint of IP traffic (botnets) they can also impact the network layer of the service. Such an attack is non-trivial. Still, as I said, DDoS is not 100% effective. You can for example use a CDN like Akamai to distribute content with little worry of the network layer becoming clogged.

But all that is not so relevant to MBRs as I see it ("clearing houses" I feel mischaracterizes the function).

The MBR is an addition to the network, not a component of it. Just as your car doesn't need nitrous oxide to run, but having it can improve engine capability, MBRs going down only means the network reverts to its performance without them (remember there can be many).


Again, MBRs are an addition to what's already there. Miners don't have to use them, and the consequence is the same as it would be for normal orphan rate.

You might take more time considering how to support the idea because I conceived it for Bitcoin too. I understand Bitcoin was seeing multi-minute block propagation time, which could worsen as the network expands. Orphaned blocks are a disincentive to any miner. MBRs simply look to solve network latency which exists due to decentralization.


I agree anything less than 2.5 minute block time is probably not practical. Still block size, block time, and network ability overall are factors which affect cryptocurrency in general. I still believe it's helpful to look at ways to improve usability and chance of success for cryptocurrency regardless of our different opinions on how that ultimately looks.

Unix was better than Windows 95.. wich as won the market ?
Beta was better than VHS, wich as won the market ?

No, that's pretty much correct, I think.  It's also not hard to show that a miner's orphan rate can be written approximately as

1 - e^(-t/T)

where T is the block period, and t is time required for the other miners to download and verify the block*.  t scales with block size, as you noted, so clearly you can scale block size at the same rate as the block period, and the orphan rate is left invariant.

Thus, a system with a low transaction rate can safely get away with a smaller block period, but keep in mind it will at some point have to raise the block period to accommodate a larger transaction rate, in order to avoid wasting too much hashing power on orphans, or screwing up consensus forming.

Much better IMHO to just focus on ways of making 0-conf transactions less risky and work on building a network of payment channels* than to try to decrease the block period.  It's not like any block period tweaking is going to improve brick and mortar transactions anyway, which need to be done in seconds, not minutes.  Although there definitely does appear to be a dumb marketing gimmick aspect to it, which is unfortunate.


* More precisely, t is the fractional hashing power-weighted sum of the times required for the other miners to download and verify the block.

* https://bitcointalksearch.org/topic/announce-micro-payment-channels-implementation-now-in-bitcoinj-244656

It seems that block validation time is almost linear in block size, i.e. t = O(blockSize). If we reduce blocktime, blocks will become smaller and validation time will decrease correspondingly. In other words 10 times more frequent blocks are 10 times smaller and require about 10 times less time to validate. Am I missing something?

good evening sir I really enjoy reading the posts in this forum is like a circus! The real backers of bitcoin have more money and computer hardware to overcome any consumer based machine..Ira

Alt coins not only have no advantage over Bitcoin, they actually deteriorate the chance of crytocurrencies in general being successful. More cryptocurrencies at an early stage lead to pseudo-inflation to an extent, destabalising the price, leading to further volatility, leading to merchants getting turned off. Its not the only cause of volatility but in an extreme scenario with multiple coins being actually accepted at the same time (currently bitcoin is the only one really accepted) then it has the potential to. At a later stage when bitcoin is established this isn't really much of a threat.

The only altcoin I really have respect for is namecoin, because it builds in 'intrinsic value' into the coin, something which Bitcoin actually lacks and could use. Otherwise all the other altcoins are seriously retarded.

Look at D&T's math in the post above yours. Transaction verification can't happen at non-trivial transaction rates on general purpose CPUs with block times that short. If you want 1 minute blocks with PayPal-like transaction volumes and acceptable orphan rates you've made it so all full nodes require ASICs just for transaction verification, let alone mining.

I can see that being a requirement at some point, but not this early in the adoption curve. Maybe when we've got a "market cap" in the tens of trillions of dollars equivalent and the transaction rate is somewhere in the 100,000+/second range it would be reasonable to expect full nodes to run on specialized hardware, but by then the economy will be so well developed that there won't be any need to shorten the block time because any problems that a 600 second interval cause would have been long since solved.

We have computers that will smoke anything you can throw at us the Chinese are just spinning their wheels on this one..Ira

+1

I still think Bitcoin would benefit from moving to a 1 minute block time. Some of the benefit would be in getting a confirmation sooner in those cases when a single confirmation is all you need, and the rest is in the advantage it would give to Bitcoin's marketing message over copycats.

Regardless, it's not a big deal, and 10 minute block times have no disadvantage (and even some advantages) for the vast majority of use-cases.


There are no Bitcoin forks that offer significant advantages over Bitcoin. The innovation seen in the BTC-alt field has been quite minimal. Shortening the block time is in no way a "significant advantage", and Scrypt is arguably a disadvantage (can cause overheating in laptops).

What Bitcoin has is a significant advantage over every fork. A cryptocurrency network is more than just a protocol. It's also the size of the network and the amount of supporting businesses and services, and in this area, Bitcoin stands far above the imitators, making any interest in other networks based purely on speculation rather than a real world advantage.

This is very much unlike Bitcoin and fiat, where there are actual use-cases where Bitcoin is superior to fiat, despite the latter's much larger supporting economy.

Yeah I don't think you understand how modern DDOS work.  The attacker hits your upstream provider with hundreds of GB/s of traffic, the simply null route you to deal with the flood.  It is why DDOS are so hard to deal with.  The pipe to your server simply becomes saturated beyond your bandwidth capabilities.  You can't filter our the good nodes if they can't get to your server.

The idea that you know all miners so you can whitelist them is somewhat disconcerting as well.  You have essentially created the central mining agency.  The entity which all miners must work with to have any chance at efficient mining.  Not really sure that is the "solution" as opposed to simply using a more efficient (large) block interval.


Even at 10MB we are talking, a not so insignificant delay.  

Still lets assume for a second you overcome the philosophical and vulnerability issues of a centralized clearing house. This still means a 2 hop propogation delay.  

The critical window = (time to transmit to clearing house) + (time for clearing house to validate block) + (time to transmit to other miners) + (time for other miners to validate)

Today validating a 500 KB block can take upwards of 300 ms.  10MB would be more like 6000 ms.  Lets assume protocol efficiencies cut that in half say 3000 ms.  Remember there are two validations unless miners are just going to blindly (100% implicit trust) the data provided by the clearing house.  Say the clearing house has 100 Mbps synchronous lot latency connectivity.  The transmit time from miner to clearing house then becomes 5*8/100 = 0.4 seconds.  If there are (a guess) 50 miners using the clearing house the time to transmit to the miners is another 50*10*8/100 = 40 seconds.

Under this naively optimistic scenario we are talking 0.4 + 3+ 40 + 3 = 46.3 seconds for full validation and double hop propagation to 50 mining peers.  With Bitcoin's 600 second average block time this means an orphan rate of ~8%.  With LTC it is more like 26%.  With the idiotic 30 second block intervals used by some scamcoins it is something on the order of 80% orphans.

Now there are solutions to make block propagation more efficient.  One (not possible on Bitcoin but could be used on an altcoin) would be to use a simplified transaction structure.  I have done some modeling and see a roughly 60% reduction in block size is possible (i.e. 1.7x as many tx in the same sized block).  For Bitcoin/Litecoin a soft fork where block is separated into header and tx set would allow more efficient pre-propogation of transactions.  Still at the end of the day smaller block intervals are going to face scaling challenges much quicker and an increased loss of security due to orphans is inevitable.

D&T even when I'm arguing with you I can't help but admire the usually informative technical specifics you include in your posts which I appreciate. However, for the points I award you there I must dock you some for imagination.


DDoS isn't a 100% effective or sustainable attack even with a motivated attacker and profitable target. While a target like MtGox might be profitable a site/node simply relaying mining data wouldn't seem so. But even if DDoS was employed it would be much easier to defeat than a traditional target, because you can know exactly which IPs are friendly and which to block. Remember honest miners wanting honest data have incentive to get it quickest. Problem solved.


Here we see things differently. I've participated (with some stress) in many block size debate threads. I really have trouble seeing block sizes at hundreds of MB being actually implemented in the near future. I endorsed Gavin's proposed course of a simple infinite raise allowing the market to sort out the rest, but I'm less than confident we'll see that adopted soon. His recent public comments on the issue seem to reflect my thoughts.

I think we're more likely to see either no change and more reliance on off-chain txs and alt-coins to relieve scalability pressures and/or a modest increase (say to 5/10 MB once) or modest increases at future points.

None of the alt coins have ANY advantages over bitcoin, and I'd say that most of them have serious disadvantages. An alt coin would only be worth using if it had a serious advantage over bitcoin and none do. Bitcoin was there first and that means a lot in this world.

Litecoin's faster confirmation time is actually a disadvantage as it doesn't do much aid in in-person store transaction and it results in a less secure blockchain.
Scrypt is only useful in that it isn't what bitcoin uses so there are no ASICs for it yet. If litecoin was actually useful we'd see ASICs designed for scrypt and on the market in months and litecoin mining would essentially be the same as bitcoin mining. There reason why there are no litecoin ASICs is because the market is far too small for any designers to give a damn.

Bitcoin does not need a "silver" to it's "gold". Bitcoin is divisible to 100 million pieces and doesn't "silver". I don't really get what people mean by that analogy anyways. To me it sounds like: here is Bitcoin, it is like gold. Or you have use Litecoin instead, which is like Bitcoins crippled step-brother that no one uses, isn't accepted anywhere, and isn't really as good. You can have that instead if you like. Why would anyone chose Litecoin over Bitcoin?

http://www.google.ca/trends/explore#q=bitcoin&cmpt=q
Interest is coming back

Yeah that isn't a solution.  So the attacker simply DDOS the centralized point (or few points) of failure.

Still you seem to gloss over the fact that validating a block takes a non zero time.  Most of the delay isn't actual propogation delay it is validation delay.


For example time zero your node is notified (either directly or through so easy to take down centralized MBR what has to happen before you validate the block and begin work on a new one.

1 ) You must receive the list of transactions in the block (this could be modified to a list of tx hashes to be more efficient)
1a) If protocol sends tx hashes you will need to query peers for missing txs.
2 ) You must validate that each tx is valid which means
a) the inputs are unspent outputs (lookup/locate the referenced prior tx output in the UXTO)
 b) the tx is properly formed. no invalid structure, parsing issues.
 c) pub key for each input matches the pubkey hash of the prior unspent output (i.e. hash the pubkey and match to prior output pubkey hash)
d) for each input compute the simplifed tx form, the simplified tx hash and validate the signature.  
 e) verify that the sum of inputs exceeds the sum of the outputs.  note the difference between sum of inputs and outputs.
 f) parse and verify the tx output script is valid.
3 ) compute the merkle tree and merkle root hash (which involves 2n-1 hashes)
4 ) validate the coinbase value is correct (coinbase should be <= computed subsidy based on blockheight + sum of all tx fees in 2a)
5 ) validate the timestamp is within 2 hours of mean network time.
6 ) validate the prior blockhash in header refers to a known block
6a) if prior blockhash is unknown query peers for the block in question (and perform all the steps in this process on that block)
7 ) validate that difficulty & version is correct
8 ) compute blockhash and ensure it meets difficulty target

Even given infinite bandwidth and all miners having all other miners as a peer, this process takes a non-zero amount of time.  The most time sensitive elements are indicated in bold.  The single largest by time is the validating of all input tx signatures due to the fact that it is 1 ECDSA sig validation (relatively slow process) per input in the block. 

Today with relatively low tx volume the time to validate a block is sub 1 second but as block sizes grow (think hundreds of MB and hundreds of thousands or millions of transactions) that time will rise.

Now there are some optimizations possible but propogation delays will cause increased orphan rates in the future if network volume rises even to PayPal levels (50 to 100 tps).  A smaller block interval is going to result in higher orphan rates and less security.    Why do you think Satoshi decided on 10 minutes, why not 1 minute, or 1 seconds.  It never occurred to him that smaller block intervals would be possible?  Alt-coin "designers" simply modified the code thinking shorter = better but it is compromise.   Now I am not saying Bitcoin is perfect but any block interval is a compromise between Latency and security.