Bitcoin Forum
August 31, 2016, 04:20:15 AM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 [71] 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 ... 368 »
1401  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 21, 2013, 07:41:15 AM
If we want to cap the time of downloading overhead the latest block to say 1%, we need to be able to download the MAX_BLOCKSIZE within 6 seconds on average so that we can spend 99% time hashing.

At 1MB, you would need a ~1.7Mbps  connection to keep downloading time to 6s.
At 10MB, 17Mbps
At 100MB, 170Mbps

and you start to see why even 100MB block size would render 90% of the world population unable to participate in mining.
Even at 10MB, it requires investing in a relatively high speed connection.

Thank you. This is the most clear explanation yet that explains how an increase in the maximum block size raises the minimum bandwidth requirements for mining nodes.

Given this bandwidth limitation, here's a new proposal for the adjustment of maximum block size:

1) A boolean flag is added to each block. The flag represents the block solver's yes or no vote for increasing the block size. The independent miner or mining pool sets this flag according to their preference for an increase.

2) Every time the difficulty is adjusted, the number of yes votes is counted from the last adjustment. If the number of yes votes is greater than 90%, then the block size is increased by 1%. Both percentages are baked-in constants, requiring a hard fork to change.



Interesting, an intergrated voting method.  I can't say which direction that I'd consider it more likely that most miners would prefer, which is a good sign that it's a viable solution.  However, I don't know that I'd agree that a 1% change per difficulty adjustment is going to be enough.  After all, there will only be roughly 26 such adjustments in one year.  Taking into account the compounding of prior adjustments, off of the top of my head I'd guess that it's not possible for the blocksize to increase by more than 35% in one calender year.  And only then if all the vote adjustments move in the same direction.  I'd say a better number would be 5% per adjustment if the vote was a supermajority (i.e. 80% of votes in one direction) or 2.5% (or so) for a simple majority.  This would, at least, make it possible for the blocksize to double in a calender year, even if it doesn't make such an outcome likely.
1402  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 21, 2013, 07:31:24 AM
If we want to cap the time of downloading overhead the latest block to say 1%, we need to be able to download the MAX_BLOCKSIZE within 6 seconds on average so that we can spend 99% time hashing.

At 1MB, you would need a ~1.7Mbps  connection to keep downloading time to 6s.
At 10MB, 17Mbps
At 100MB, 170Mbps

and you start to see why even 100MB block size would render 90% of the world population unable to participate in mining.
Even at 10MB, it requires investing in a relatively high speed connection.


And practically speaking, most people would like to be able to use their broadband connection for other things.  Offically, my cable service is a 10Mbit/sec connection, but practically I can't sustain more than 1.5Mbps to any single IP address.  If I let my bittorrent client full access, it peaks around 1.5Mbps but averages about half that.  Your bandwidth needs are further complicated by the fact that once you have downloaded and verified a block, you're expected to then upload that block to your connected peers.  Since most broadband connections are half as fast uphill, this limits your connected peer's download to half of what you're offically capable of.  In conclusion, anything beyond a 1MB limit is too resource intensive for the at-home full client to be able to keep up with at present, but with the advancements in Internet tech and infrastructure, we can assume that an at home connection would be able to manage a 10-20 MB block within a decade.  We would want to aim for the hard limit to be at least this high, while continuing to depend upon soft limits in the meantime.

Quote

Also of importance is the fact that local bandwidth and international bandwidths can wary by large amounts. A 1Gbps connection in Singapore(http://www.starhub.com/broadband/plan/maxinfinitysupreme.html) only gives you 100Mbps international bandwidth meaning you only have 100Mbps available for receiving mining blocks.

International bandwidth is much more complicated than this, with respect to a p2p network such as Bitcoin.  Much like bittorrent, the bandwidth for Singapore is functionally replicated for all of the Bitcoin clients in all of Singapore, so it's not true that the international connection is divided among the many peers all trying to download the same block, it's effectively shared data as if there were a locally available seed on Bittorrent.  Granted, it's not the same as saying that all of Singapore could be regarded as one node, and then the block replicates across the entire nation-state from one copy; but once one copy of the block has made it across the bottleneck, the local bandwidth effectively becomes the limiting factor to propagation.
1403  Economy / Gambling / Re: The unprofessional look to sites on: February 21, 2013, 01:48:01 AM
I am not trying to start a sh** storm here I just am wondering what a lot of these sites see as a long term goal.

I have to say the majority of sites for BTC gambling (and many other things for that matter) look very unprofessional and like Joe Ijustwantyourmoney coded them.  Interfaces from the 80s and some non existent IMO.

I remember the same complaint from some people when Craigslist was new.

It's not about the pretties, it's about the content.  And these sites are very much targeted to a worldwide, but mostly English reading, customer base.  There are way too many websites these days that functionally require either a broadband connection or an image filtering system just so that they can be navigated.

I have broadband, but I still miss the "load images" button that early Netscape browsers had.  I don't doubt that a great many end users, particularly those in nations werein broadband is still rare and bandwidth usage is metered, very much appreciate the low-bandwidth nature of many Bitcoin related sites.
1404  Other / Beginners & Help / Re: Newbie restrictions on: February 21, 2013, 01:39:27 AM
Why was the post restriction put in place even for really old accounts?  Huh

Simplicity.  The number of really old accounts with less than 5 posts would be really small.
1405  Other / Beginners & Help / Re: Newbie restrictions on: February 21, 2013, 01:38:26 AM
Hmm are we supposed to just spam here?

Pretty much.  Talk like a human, though.  The main goal is to catch spambots before they make it into the main forum, which makes their presence both more annoying and more difficult to clean out.
1406  Other / Beginners & Help / Re: Introduce yourself :) on: February 21, 2013, 01:26:37 AM
I am like the earth, but with corners. 

Dude!  I've had that dream!  Air was thin at the corners.
1407  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 21, 2013, 01:22:52 AM
I don't understand. XMiningPool Inc. mines a block at 600kb. You ignore it. So in your block chain you go from 250,000 to 250,002?

No, I'm not saying that I actually reject an otherwise valid block, because it's bigger than I like.  That would certainly force a hard fork.  I'm saying that, as a client, I have a rule that does not forward blocks over my chosen limit to my other peers. If I'm alone, or otherwise in the minority on the issue, I've caused zero harm to anyone while managing to save myself some bandwidth.  However, if any significant minority of the total number of full clients that participate in the network, whether or not they mine themselves, also adopt this rule; the effective result is that this creates a delay in the propagation of overlarge blocks, effectively granting a bandwidth advantage to miners who choose to stay within the soft limit.  Thus, miners who create blocks over the limit effectively have their hashrate handicapped by delays in propagation.  As for myself, even if the block is overlarge, if it passes the standard "hard" block validity rules, it still does not get rejected from my own blockchain, as that would prevent myself from participating in the network in the event that said overlarge block is still the one that is built upon.  I'm doing nothing with my soft limit rule other than choosing not to forward the block.  

My highlighted sentence above implies that as the bandwidth requirements increase for full nodes, someone is going to implement something functionally similar anyway, in order to save bandwidth.  Worse would be for some programmer to take the easy route, and simply modify the code so that a full client quietly never forwards a valid block to it's peers, and it's peers never notice.
1408  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 21, 2013, 01:01:41 AM
I've done nothing of the sort.  If I add a rule to my client that it quietly drops blocks that are over 250Kb, what have I done to you?

Nothing, but you've kicked yourself off the network (until a majority of mining power + a significant amount of full nodes on the network implement your rule too.

No, I haven't.  You don't even know that I dropped your block.  I can participate as a node just fine, just not as a miner.  It's a balance of forces.
1409  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 20, 2013, 11:53:37 PM
Include the soft limit into the verification rules of as many clients as possible, and miners who first comment out that rule for themselves will be punished by the network at least until a majority of users upgrade their clients to match.  The rest of the miners that didn't commetn out the rule would benefit from teh harm the first mover takes upon himself.

Huh...wha...eh??? This makes no sense. The "soft limit" is not a verification rule, it is part of the algorithm that the mining example code uses to put together a candidate block. It stops when it reaches 250kb. This doesn't mean that miners will reject blocks that are over 250kb, it just means that they will not PRODUCE them (unless someone modifies the code).

I know what it means.

Quote
Making the 250kb a verification rule of clients is a fork (not sure if its a hard fork or a soft fork). It makes no sense to do this. You can't assume that everyone is going to upgrade to this version, nor should you assume that once this rule is adopted by clients that it will ever go away. You have effectively reduced the 1 megabyte hard limit down to a 250 kilobyte hard limit. Good job, LOL, the opposite of what people are arguing for here!  Cheesy  Cheesy  Grin

I've done nothing of the sort.  If I add a rule to my client that it quietly drops blocks that are over 250Kb, what have I done to you?  Unless a majority of users also do so, I've done nothing.  Perhaps I dno't drpop it from my own chain, I just don't forward it.  It's something that I can do right now, and it's only effective if a significant number of others also do so.  However, if it does exist, it's presence becomes an enforcement mechanism upon the soft limit that miners presently abide by, that can be easily removed simply by a significant portion of the users agreeing that it should be done, and upgrading to the next versiuon of their client that has a higher soft limit.

For all we know, there are already clients that quietly drop blocks based upon the block reward address not being in their whitelist, or any other such metric.  Or even randomly.  None of this would matter until half of users followed the same rule.
1410  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 20, 2013, 11:39:16 PM
The problem is the baseline and how much of a difficulty change equals how much of a block size limit change. The baseline could be how much difficulty is at the time of the change (for example), but the other part is tricky. Maybe it could be done as a percentage change, it would change the same percentage as difficulty?

This is what I mean when I say that an oracle would be needed to determine the formula relating difficulty to block size. There is absolutely no way to know what this formula would look like. The penalty for getting it wrong (and it would be wrong most of the time) is vanishing fees, resulting in hysteresis (wild oscillations in network hash rate). ASCIMiner's 24% of the network hash rate could become 51% after a difficulty adjustment.

What's wrong with the scheme I described, which responds directly to changes in transaction space scarcity?

If we...use soft limits and/or other block verification rules to impose scarcity on transaction processing, most of the miners & pools will abide by the soft rules even when commenting out those rules is provablely in their own economic interests.  Reputation matters here, even moreso than it does in the "real" business world.

False. At least one of the pools will rewrite the soft limit to their economic advantage. Once this happens, members of other pools will quickly abandon ship and join the pool that modified the soft limit, since they have higher payouts.

You're saying that miners will choose to make less money rather than more? Huh Huh

I can see it now: "p2pool: smaller payouts, better reputation!"

Yeah, I don't think so.


Not a certainty; so don't depend entirely upon limits that can be commented out by miners.  Use block verfication rules as well, which could be commented out by the users, but why would they do this?  The propogation of the block is very much part of the system.  Include the soft limit into the verification rules of as many clients as possible, and miners who first comment out that rule for themselves will be punished by the network at least until a majority of users upgrade their clients to match.  The rest of the miners that didn't commetn out the rule would benefit from teh harm the first mover takes upon himself.
1411  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 20, 2013, 11:22:18 PM
and how much of a difficulty change equals how much of a block size limit change. The baseline could be how much difficulty is at the time of the change (for example), but the other part is tricky. Maybe it could be done as a percentage change, it would change the same percentage as difficulty?

Or it could be a hybrid of your two ideas.  The increase in difficulty triggers an increase in the blocksize, but not linerally.  For example, no matter how much the difficulty increases (beyond a minimum), the blocksize increases by 10%.  No matter how much the difficulty decreases (beyond a minimum) the blocksize decreases by 5%.  Or vise versa, depending upon which is more likely to result in a favorable sscarcity.

Throw in my unlimited-if-all-free transactions rule.
1412  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 20, 2013, 11:15:19 PM

Any adjustment to the maximum block size must preserve scarcity. The question is not how many transactions can be handled by a one gigabyte hard limit, but rather will a one gigabyte hard limit produce sufficient scarcity?


I don't agree that the hard limit is the only way to promote scarcity.  Bear in mind, no matter how we do this, the scarcity is still artificial.  If we don't do it right with a hard fork, we're stuck with it.  If we increase the hard limit to a high predicted future limit, and use soft limits and/or other block verification rules to impose scarcity on transaction processing, most of the miners & pools will abide by the soft rules even when commenting out those rules is provablely in their own economic interests.  Reputation matters here, even moreso than it does in the "real" business world.
1413  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 20, 2013, 11:07:59 PM
Another possible solution to the scarcity of transaction space versus an infinately growing transaction queue (with infinately growing free transaction confirmation delays) is to permit an unlimited (or massively huge limit) block to legally occur under specific conditions that would not incentivise miners towards anti-competitive activities.

For example, there could be an exception rule for the blocksize limit if zero fee paying transactions were included into the block.  This rule would permit a miner to queue dump for his own reasons, be it that his queue is too large, it's owned by a major bitcoin holder that simply wishes to help the network at his own expense, or a major retailer (think WalMart) that has a huge amount of free transactions from customers to process, and mining isn't directly their business model.

Another method would be to permit an un-limited block based upon an interval that miners could not depend upon.  For example, the difficulty is adjusted every two weeks or so, but the difficulty adjustment block could also be an unlimited block, also permitting (perhaps expecting) the miner that finds that block to not only include every single fee paying transaction in the block, but also every single transaction still in his queue.  This would limit the delay for free transactions to a two week maximum, and only burden the bandwidth challenged clients and miners once every two weeks and on a predictable schedule.

Occasionally flushing the transaction queues would benefit all players, without significantly impacting the scarcity of transaction space for the remainder of the time period.  However, the second method is likely to encourage free transactions leading up to the unlimited block's expected arrival; whereas the prior method of permitting unlimited blocks based upon a fee-less transaction queue would not encourge same, but nor could users be certain that their free transactions be processed in any reasonable time frame, as there is not way to be certain that any miner would be willing to do this.
1414  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 20, 2013, 10:47:47 PM
I don't trust off-blockchain transactions...Especially with...the "threat" that they could be executed by being put into the blockchain at any time

Keep in mind that when we talk about off-blockchain transactions, we are talking about alternate block chains. These would be separate crypto-currencies with different properties. Ripple is one example (it relies on trust, unlike Bitcoin). I'm sure there will be others when the opportunity for profit arises.


No we are not.  At least I'm not.  I'm talking about off-network Bitcoin transactions, of any type, but that are still denominated in bitcoins.  This could be people who trade in sets of private keys (unsafe, yes; but possible), it could be people who trade in a paper currency denominated and/or backed by a bitcoin reserve, or this could be people trading within a single online wallet service (think Ebay, using something like MyBitcoin.com rather than Paypal as the default transaction method) or a potential parrallel network of wallet services that function like banks, taking the Bitcoin equivilant of bankchecks and settling up with one another on much longer intervals.

All of these methods, at least all that I can think of, require more trust between parties and involve greater risk than using the main Bitcoin network; but that is also why they would be a cheaper alternative most of the time.  If you're going to be buying/selling a car with bitcoins, you're going to want to use the Bitcoin network; but if you're buying a snickers bar at the store, a standardized method of trading private keys might be a viable alternative to a blockchain transaction fee.  Microtransactions were never Bitcoin's strong point; distance & high security with low trust were.  Not all transactions require that kind of certainty.

Quote
Quote
I'd rather see a dynamic solution...

There are a lot of things we'd rather see but the point being made is that there are limits to what can be done with Bitcoin, while keeping it Bitcoin (global consensus, proof of work, etc...) Raising the block limit by a non-trivial amount may not be practical.

It should be easy to see that if there was no limit on block sizes, that fees would trend towards zero (ignoring the OP's original stated problem of miners attacking other miners by producing large padded blocks). Do you understand that with increasing block sizes come smaller fees?

For that matter I've seen a lot of talking about bandwidth, storage, and processing power but it seems everyone has overlooked that:

Fees will decrease as block size is increased (all else being equal)

Do people not get this, or am I wrong?


I get this, and I agree from an economic incentives perspective.  This is the very same problem of scarcity that prompted a minimum fee rule, in order for a transaction to be considered a fee paying transaction according to the priority score algo that Gavin put in a couple of years ago.  The limits prompt delays in free transactions, and that is a cost to consumers.  Wise consumers will pay a fee for speed, but not more than they must.  If the transaction fees can ever be expected to replace the decending block reward, there must be some kind of scarcity there.  If we remove the limits altogether, the supply of transaction space will (functionally) be as close to infinate as the supply of bandwidth availabe to email spammers.  There will be no incentive for the majority of users to contribute a fee, even after the block rewards decrease to nominally zero, unless they are running up against some kind of limiting resource.  I believe that free transactions should always be possible, but if speed of confirmation is the concern you're going to have to contribute.  We can suffer a lot more 'freeloading' than can VISA or Mastercard, but the network is not costless, so the service to users cannot be costless either.
1415  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 20, 2013, 10:25:10 PM
There is most likely no need to do incremental changes. There are already pretty good looking suggestions on how we can simply let miners decide the block size. To do that we would need some fairly strict rules for how long validating blocks by regular nodes can take until they are rejected. This would create a cap for the block size that is actually relative to the processing power of most full nodes. That is something we want, I think.

The other interesting suggestion was linking mining difficulty and the block size. Those are the two decent suggestions so far. Finding a long term way to fix this is much better than simply making a one time increase. If there is a one time increase, it should be a massive increase together with a smaller soft limit, so that the soft limit can be raised more easily in the future if necessary.

While I can see your point, I still think that there should be a hard limit, however high that might be.  In this way, there is always an absolute for which large miners 'cheating' by trying to force out smaller players (via padding of the transaction queue or similar) will run into that limit.  Hopefully this absolute limit will discourage those unscrupulous players from turning to the dark side, simply based on the idea that there are going to be a percentage of players that they could not force out of the mining business, no matter how much larger they could grow on a relative basis.

However, upon further thought, I think that said hard limit should be pretty freaking high, in order to allow the soft limit to be our control method for many more years without further need of hard forks.  And if we are going to do this hard fork against the desires of some miners (which is probably a certainty) it's better that we get to it sooner rather than later.  If we start bumping up against the hard limit, some miners might just manage to profit from that artificial scarcity in ways that would turn a good portion of the miners aginst the idea of a hard fork, whereas they might otherwise not oppose one before we get there.

How high would such a hard limit be?  Can we estimate how many transactions per second that, say, a one Gb hard limit could process?  As already pointed out by many, we don't need to accommodate all of the transactions that occur in the world; but we need to be able to do much better than 7 per second.  What is a good target?  VISA's transaction volume?  Paypal's? Or VISA + Mastercard?  Once we decide, then we need to set it and let it go, and be willing to let the market in transaction fees and off-network transfers simply run.  We are going to get way too big to do this kind of thing twice.
1416  Other / Beginners & Help / Re: Wouldn't it be more fair if the bitcoins were shared equally? on: February 20, 2013, 07:08:19 PM

It's not the same, I don't mind people buy things that get higher value in the future. This is not the case here, Money doesn't have a value on it's on, it's the ability to get things from it, that give it a value. This is about a currency system that wants to replace the current one, now people can decide if they want to cooperate with it or keep using the current one, and if people feel that the system made in such a way that some people will be richer than the others only because they invented it or were the first to join, people won't want to join it, and if people won't join it this system can't live, and the people also know they can harm the system by not joining it.


Not only do you not understand Bitcoin, you don't even understand what money generally is.  What you want to do is literally impossible.  Yet, you are free to try it on your own.  We wouldn't try to stop you, although a great many of us are going to be quite amused at your attempts.  If you're right, you'd be a hero.

But you're not right.  Currencies are an amoral tool.  Nothing more, nothing less.  The fact that you disagree with how this one was designed makes no difference at all.  Are you going to claim that you do not use fiat currencies to live?  The nature of those currencies are far worse than anything that you imagine that Bitcoin may be.  That is what the alternative actually is.  What you would wish for is immaterial unless and until you, personally, make it happen.  Right now, what you want is not a choice, and no matter what you say on this forum, Bitcoin isn't going to change to suit your illusions.
1417  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 20, 2013, 07:01:14 PM
There's one possibility that I'm surprised no one has mentioned. That the rise and performance of Bitcoin as a store of value (forget about fast payments) creates competitive pressure on fiat currencies to stop inflating and remove capital controls. Wishful thinking? Or could fiat currencies become the "alt chains" needed to fill in the gaps?

They already are.  Bitcoin is not intended to, nor is it likely to, replace national currencies.  It's going to be a long time coming before Bitcoins displace paper cash in small daily transactions.  That said, it's not unreasonable to assume, should the central banking model not be able to adjust to the reality of Bitcoin (and presumedly not be able to destroy it), that new paper cash currencies that claim a reserve backing of bitcoins that displace national fiat currencies.  So yes, in many cases simple paper cash would function as an "alt-chain" just fine; although I'd predict that should a bitcoin backed banknote ever come into existance, it's more likely to be a plastic token with a digtial artifact imbedded into it, probably using many of the very advanced security features that casino tokens use today.  And just like the gold in a vault never actually moves under a (auditable) gold standard, the bitcoins that presume to back those banknotes would rarely, if ever, need to move across the blockchain.  The important part to all this is that, in the end, any peer forever has the ability to move transactions across the blockchain.  That is the part that makes it 'decentralized', not the number of network nodes (although that is an important minimum) or the common size of a mining operation.  The important part is that there are no 'super-nodes' with special abilities to ignore or exclude other nodes from the network.  If the block-max-size issue ever started to trend toward nodes that were so much larger than the entry level node as to functionally have the ability/incentive to ignore the small nodes, and have that actually work, then I'd be concerned.  I do not claim to know what is the best method for increasing the blocksize limit, but I do not believe that increasing it to 10mb, 20mb or even 50mb as a hard limit would be a dramatic burden on most full nodes.  Perhaps a combo solution; a higher than currently reasonable hard limit combined with an adjustment algo for a soft limitation.  For example, the hard limit could be set to something like 250Mb, and an algo that can adjust the soft limitations within that hard limit withn a range based upon, perhaps, the average number of blocks delayed that a minimum fee transaction experiences during the prior two week period. 

Although I havn't a clue how that could be actually implimented.
1418  Economy / Trading Discussion / Re: Is it possible for an exchange to manipulate prices for own profit? on: February 20, 2013, 05:34:56 AM
Of course it's possible.  You're trusting that the exchange sites are honest.  These trades are onsite, not on the blockchain, so there is no way to be certain that they are not, in practice, manipulating the exchange prices to their own benefit.

I've pretty much assumed that they do this as a matter of course for three years, but whatever they might actually be doing, doesn't shift the official price by much or for long.  Any bot making trades over a one cent move still makes money.
1419  Bitcoin / Bitcoin Discussion / Re: Could Bitcoin be a solution for the raw milk market? on: February 20, 2013, 05:24:53 AM

http://en.wikipedia.org/wiki/Lactose_intolerance

On another note I wonder why buying raw breast milk is legal in the US?

It's not.
1420  Bitcoin / Development & Technical Discussion / Re: How a floating blocksize limit inevitably leads towards centralization on: February 19, 2013, 11:23:39 PM

Yeah I know that is not realistic. But it seems to give some insight into the numbers, at least to me. Full nodes seemingly are not settling up even as often as qarterly right now, why is that? Is it that actually there are only about 10,000 individual users actively transacting currently at any one time / on any given hour or during any given day or something like that?

-MarkM-


None of the above.  If there are 10K full nodes, then there are 10K copies of the blockchain.  That is all that this implies.  There is no data to tell us; 1) how many are single user nodes versus how many are multi-user nodes or Stratum servers, 2) how many users on any of these light client servers exist nor 3) how often these users need to "settle up".  The actual number of the full clients in the network is mostly a product of the "many-copies-keeps-data-safe" security model.  But the cost of this redundency is not zero (even though it's still cheaper than fiat currencies).  This cost would be spread out greater as the market grows, but the resources that miners consume are not the only costs of running the network, as a great many of those resources are contributed in-kind by users with both the resources and the determination to run full nodes.  As the resources required to participate in the network as a full node increase (at a rate faster than those same resources grow, as available to the average power user) some of those back-up nodes with marginal/non-existent pay-back will stop participating.  Hopefully, the services of running a parrallel payment network, for example BitcoinSpinner's business model, will be able to turn a profit, since they will (out of necessity) also run a full node.
Pages: « 1 ... 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 [71] 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 ... 368 »
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!