Bitcoin Forum
November 24, 2017, 05:57:27 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: What is still driving the enthusiasm of bitcoins over other currencies?  (Read 3010 times)
stdset
Hero Member
*****
Offline Offline

Activity: 573



View Profile
July 06, 2013, 04:44:04 AM
 #21

as block sizes grow (think hundreds of MB and hundreds of thousands or millions of transactions) that time will rise.
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?

1511503047
Hero Member
*
Offline Offline

Posts: 1511503047

View Profile Personal Message (Offline)

Ignore
1511503047
Reply with quote  #2

1511503047
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
d'aniel
Sr. Member
****
Offline Offline

Activity: 461


View Profile
July 06, 2013, 09:31:32 AM
 #22

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?
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://bitcointalk.org/index.php?topic=244656.0
DoomDumas
Legendary
*
Offline Offline

Activity: 991


Bitcoin forever !


View Profile WWW
July 06, 2013, 05:44:50 PM
 #23

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

Activity: 1036


View Profile
July 06, 2013, 05:56:58 PM
 #24

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.

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).

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.

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.

Quote
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.

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.

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.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
July 06, 2013, 05:57:21 PM
 #25

Unix was better than Windows 95.. wich as won the market ?
Beta was better than VHS, wich as won the market ?
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.
stdset
Hero Member
*****
Offline Offline

Activity: 573



View Profile
July 06, 2013, 07:02:10 PM
 #26

1 - e^(-t/T)
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.

d'aniel
Sr. Member
****
Offline Offline

Activity: 461


View Profile
July 06, 2013, 08:50:25 PM
 #27

1 - e^(-t/T)
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.
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 Smiley  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.

Quote
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.
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.
rdrdigital
Newbie
*
Offline Offline

Activity: 15


View Profile
July 06, 2013, 10:51:44 PM
 #28

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.
stdset
Hero Member
*****
Offline Offline

Activity: 573



View Profile
July 07, 2013, 05:02:36 AM
 #29

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.
That kind of analysis would be interesting. I look forward to read about it.

amincd
Hero Member
*****
Offline Offline

Activity: 772


View Profile
July 07, 2013, 08:54:16 AM
 #30

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.

+1

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.

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.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!