Kluge (OP)
Donator
Legendary
Offline
Activity: 1218
Merit: 1015
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 03:22:08 AM |
|
I can't keep up with the blockchain anymore. I am now roughly 150 blocks behind.
I cannot run Bitcoin-qt during the day because I'm on a tethered 3g connection and do actually need to use most of the available 5-150kbps of bandwidth during the day. My only available alternatives are dial-up, which simply couldn't keep up with the blockchain even if on 24/7, and satellite, which, aside its terrible latency issues, has bandwidth caps harsh enough to make downloading the blockchain a two-week process. I'm a bit beyond the Last Mile zone, which most people probably don't have to deal with, but many more people do have to deal with increasingly-common bandwidth caps, and certainly not just with satellite and mobile ISPs.
Where am I to go, but a centralized server handing me only information they deem true and relevant? What am I to do, but throw away the largely zero-trust system I was initially interested in? There are alternatives in the "Lite" world.... Some people let me "own" my coins, instead of tossing it all in a collective wallet. Some people are even generous enough to allow me to keep my privkeys to myself. If their service goes down, I could go to another private entity, but I can never again hold what the majority agree is "the blockchain" - just what small groups of people, or individuals, tell me the blockchain is.
I love Armory. It's a fantastic product. I need a blockchain to use it, though, and I can't keep up. I can go to family/friends' houses to leech off their cable connection, so I'll see transactions days after they happen. Maybe the migration to lite clients isn't necessarily bad, but I don't think active nodes shutting off could possibly be considered good.
So what can we do? Expand our definition of "dust" and further limit freedom to use Bitcoin? Do we forfeit the zero-trust vision? Do we wait for a real solution? How much longer? ... Someone sent me a couple BTC this morning. I wouldn't have known if he didn't email me.
Anyway - enough wispy bullshit -- Is there a solution I'm missing, or one in the works? Or should I just suck it up, quit my bitching, and download Electrum?
|
|
|
|
grau
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 06:49:17 AM |
|
Anyway - enough wispy bullshit -- Is there a solution I'm missing, or one in the works? Or should I just suck it up, quit my bitching, and download Electrum?
I am afraid that any remedy will only push out your timeline running a full node a few months or a year. You will have to decide to be in the business of running a full node, that will become as serious as it is now to be a mining pool operator, or you move your bitcoin with most of the customer to a tablet. Above statements are not ideological, just rational thinking. I also regret that times of all having equal "vote" will be gone. They are actually already gone. A mining pool operator has more than equal "vote" compared to your full node since long, e.g. he can exclude transactions from blocks, you do not. You will hardly win a real world argument against blockchain.info with a merchant remote from you by pointing to your screen. I work on an implementation that aims to support creation trustworthy centralized services, unlock innovation so we preserve as much of the the zero trust environment as possible. The future will unlikely be a homogenous set of nodes, since it is not already. Peter works on a short term remedy with 0.8 for us.
|
|
|
|
FreeMoney
Legendary
Offline
Activity: 1246
Merit: 1016
Strength in numbers
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 06:55:15 AM |
|
I'm not 100% sure, but supposedly 0.8 will be fast enough that processing won't be the bottleneck anymore so the maximum you would have to download each day is ~6x24 = 144MB. And in reality it's like 10% of that now.
|
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
|
|
|
FreeMoney
Legendary
Offline
Activity: 1246
Merit: 1016
Strength in numbers
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 06:58:21 AM |
|
I also regret that times of all having equal "vote" will be gone. They are actually already gone. A mining pool operator has more than equal "vote" compared to your full node since long, e.g. he can exclude transactions from blocks, you do not.
That's as silly as saying that the 'olden days' of bitcoin didn't give equal votes because my mother (she doesn't mine) couldn't exclude transactions. She could have if she cared and so can any current miner. Do you think pool operators are special? They are just people who care to do what is required by the actual laws of physics to set up blocks for mining.
|
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
|
|
|
Stephen Gornick
Legendary
Offline
Activity: 2506
Merit: 1010
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 11:11:01 AM |
|
There are alternatives in the "Lite" world....
You get the blockchain headers with Simplified Payment Verification (SPV) clients, such as MutliBit.
|
|
|
|
Meni Rosenfeld
Donator
Legendary
Offline
Activity: 2058
Merit: 1054
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 11:19:39 AM |
|
See Ultimate blockchain compression w/ trust-free lite nodes. It was never intended for every user to run a full node. I haven't followed up on the details of the above suggestion but AFAIK it's viable and, once implemented, allow using an SPV client without need for trust. Also, while people in your situation shouldn't be neglected, I don't think it's the norm. I think enthusiasts will be able to run full nodes for quite a while.
|
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1129
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 02:34:19 PM |
|
We will soon be merging support for Bloom filtering into Bitcoin and bitcoinj. This will allow you to have SPV level security without downloading the whole block chain - just headers and relevant transactions. It means as long as honest nodes control the majority of the hashing power, you can trust the block chain to be correct.
This mode will give you what you want. So it's just a matter of time. I'm hoping we can have a testing setup you can use in the next few weeks, at least, with release some time after that.
|
|
|
|
blueadept
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 04:15:41 PM |
|
Mike, do you know if Bloom filter support is intended for the Bitcoin 0.8 release or after that?
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4228
Merit: 8641
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 08:15:20 PM Last edit: December 31, 2012, 08:25:55 PM by gmaxwell |
|
I cannot run Bitcoin-qt during the day because I'm on a tethered 3g connection and do actually need to use most of the available 5-150kbps of bandwidth during the day. The absolute maximum long term average bandwidth pulling the blockchain can take is about 13.3kbit/sec. I'm not sure what the source of your issues is— it may be due to bandwidth used relaying blocks and transactions to other peers, but you do have enough bandwidth to stay synchronized— at least to within a couple blocks of most current. Claims like "I am afraid that any remedy will only push out your timeline running a full node a few months or a year. " are just factually untrue on the data that you've provided. And, if the "business of running a full node, (...) become(s) as serious as it is now to be a mining pool operator" then bitcoin will be dead and pointless, because running a full node has no _business case_ as it can't be directly monetized and there is always an incentive to let someone else take the cost if the cost is great enough to not be inconsequential. If fairly few parties run Bitcoin, then Bitcoin would fail at its purpose of requiring less trust than the commercial banks of democratic nations, as their trust model is stronger. Fortunately, the design of the Bitcoin actually prohibits this loss of decentralization from happening— Blocks have a maximum size (and the size of blocks nodes will create is further artificially constrained by current implementations), and this bounds the cost of running a full node. This size can not be increased without a hardfork of identical technical complexity to changing the supply of coins— so to pull it off it would have to be utterly uncontroversial, and presumably people will always stand up to insist Bitcoin remain practically decenteralized. The maximum cost is still a bit high relative to current hardware, but it won't be in a couple years with a few more cranks of the silicon and storage scaling laws. That said, for a mobile connection— a thin or lite client is the obvious thing to use. Ideally, you could run one behind a full node that you have absolute trust over (E.g. because you own it), and then you don't even need to worry about the potentially reduced trust model involved. But it would still be interesting to figure out why your node isn't keeping up.
|
|
|
|
Meni Rosenfeld
Donator
Legendary
Offline
Activity: 2058
Merit: 1054
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 09:00:12 PM |
|
I cannot run Bitcoin-qt during the day because I'm on a tethered 3g connection and do actually need to use most of the available 5-150kbps of bandwidth during the day. The absolute maximum long term average bandwidth pulling the blockchain can take is about 13.3kbit/sec. I'm not sure what the source of your issues is— it may be due to bandwidth used relaying blocks and transactions to other peers, but you do have enough bandwidth to stay synchronized— at least to within a couple blocks of most current. Claims like "I am afraid that any remedy will only push out your timeline running a full node a few months or a year. " are just factually untrue on the data that you've provided. And, if the "business of running a full node, (...) become(s) as serious as it is now to be a mining pool operator" then bitcoin will be dead and pointless, because running a full node has no _business case_ as it can't be directly monetized and there is always an incentive to let someone else take the cost if the cost is great enough to not be inconsequential. If fairly few parties run Bitcoin, then Bitcoin would fail at its purpose of requiring less trust than the commercial banks of democratic nations, as their trust model is stronger. Fortunately, the design of the Bitcoin actually prohibits this loss of decentralization from happening— Blocks have a maximum size (and the size of blocks nodes will create is further artificially constrained by current implementations), and this bounds the cost of running a full node. This size can not be increased without a hardfork of identical technical complexity to changing the supply of coins— so to pull it off it would have to be utterly uncontroversial, and presumably people will always stand up to insist Bitcoin remain practically decenteralized. The maximum cost is still a bit high relative to current hardware, but it won't be in a couple years with a few more cranks of the silicon and storage scaling laws. That said, for a mobile connection— a thin or lite client is the obvious thing to use. Ideally, you could run one behind a full node that you have absolute trust over (E.g. because you own it), and then you don't even need to worry about the potentially reduced trust model involved. But it would still be interesting to figure out why your node isn't keeping up. Yes, increasing the block size limit has identical technical complexity to changing the supply of coins - that is, no complexity at all. Changing the supply of coins has economic/social complexity - people signed up to Bitcoin on the premise that the value of bitcoins are maintained by their scarcity, with a specific inflation schedule. Changing that will destroy the Schelling point and nobody will agree to it. On the other hand, nobody signed up to Bitcoin on the premise of a specific block size limit, so when it becomes necessary the change will be uncontroversial and fairly easy (change the client to have increased size limit starting from block 270,000, giving everyone half a year to upgrade). If Bitcoin is ubiquitous there will be about 10K Bitcoin payments per second. A block size limit of 1MB will allow about 1 transaction per second. This means that 99.99% of payments will be outside the blockchain. So you will have this beautiful decentralized system that everyone can run but nobody can use, they will have to resort to 3rd party alternatives with various trust requirements. There will still be some benefit from having Bitcoin as the foundation, but that diminishes the more expensive it is to actually do a real Bitcoin transaction. It's more likely the block limit will be raised eventually to about 100 MB. People won't be able to run a full node on their cellphones, but any enthusiast will still be able to do it on a PC, and it will allow for 1% of payments to take place on the blockchain. It's still sufficiently decentralized and is now also useful.
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4228
Merit: 8641
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 09:24:20 PM |
|
economic/social complexity - people signed up to Bitcoin on the premise that the value of bitcoins are maintained by their scarcity, with a specific inflation schedule. Changing that will destroy the Schelling point and nobody will agree to it. On the other hand, nobody signed up to Bitcoin on the premise of a specific block size limit,
The scarcity of bitcoin's can not be maintained without security, the worth of Bitcoin as a transaction medium can't be maintained without security. The comparitive benefits of Bitcoin over alternatives depend on decenteralization. Security and decentralization are not possible without block size scarcity. I certainly signed up for limited size blocks— and so did Satoshi, as the limit is baked into the code not just a soft limit— as many limits are (including the 500k maximum block target)— but a hard network rule. Absent this rule Satoshi's economic argument that fees will eventually provide the incentive for honest participation once the subsidy has become small is invalid. There _must_ be competition for block space to make fees a viable way to pay for security. Without a limit which is reasonably within the bounds of inexpensive hardware there will be great pressure to let someone else handle the validation, and you end up with an outcome similar to the central banks in democratic countries. Bitcoin would be just another very technically inefficient way to have a trust laden monetary system. So you will have this beautiful decentralized system that everyone can run but nobody can use, they will have to resort to 3rd party alternatives with various trust requirements. The overwhelming majority of gold and USD transactions are not done with gold bars or US bills— can no one use these currencies. Your use of 'Various' there is deceptive. Various means people have a choice. It's perfectly possible to build fully decentralized payment system denominated in Bitcoin. But if Bitcoin itself is bloated then these options can't exist because they they would have both their own high cost of operation plus the unimaginably high cost of operation of a bitcoin shipping around gigabyte blocks. It's more likely the block limit will be raised eventually to about 100 MB. People won't be able to run a full node on their cellphones, but any enthusiast will still be able to do it on a PC, and it will allow for 1% of payments to take place on the blockchain. It's still sufficiently decentralized and is now also useful.
And on this point we do not completely disagree, though I think 100MB is rather high. I'm not saying that adjusting the limit is a complete non-starter. Only that removing it or setting it to some value which is not utterly uncontroversial— long after most practical devices can handle it is a non-starter. My point in responding here is that arguments that it will soon be harder to handle— and only something that major businesses can support— are bogus. It may or may not be increased in the future, but if it is it will only happen to a level which is uncontroversial.
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 10:36:36 PM |
|
There _must_ be competition for block space to make fees a viable way to pay for security.
It's not necessarily the case that transaction fees are the only way, or even a viable way at all, to pay for security. Saying the block size must be kept small because that's the only way to keep transaction fees high is begging the question. No matter how decentralized it remains, Bitcoin doesn't provide any security at all if it's not used, and if 99.99% of transactions must pass through other (probably centralized) networks due to block size limits how much security is Bitcoin actually providing in real terms?
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4228
Merit: 8641
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2013, 04:50:49 AM Last edit: January 01, 2013, 05:05:39 AM by gmaxwell |
|
No matter how decentralized it remains, Bitcoin doesn't provide any security at all if it's not used, and if 99.99% of transactions must pass through other (probably centralized) networks due to block size limits how much security is Bitcoin actually providing in real terms?
The primary novel thing Bitcoin provides relative to other systems is inflation resistance. It's fairly straight forward show that a system denominated in Bitcoin is actually backed by control over the Bitcoin value they claim to control. (e.g. for example— if you have a distributed payment network based on blinded tokens, you just re-blind and publish all the the tokens, and then publish signmessages with keys in the bitcoin chain for all the coin in the system. Anyone with a token can verify their their token is in the list... and anyone can sum the tokens and see that there aren't more tokens than coins ('anyone' in these cases really just being auditing built into the software that runs randomly and publishes alerts if a discrepency is found)) You're adding the centralized requirement there— but it isn't needed, distributed and decentralized systems denominated in Bitcoin can be created— though centralization does allow certain efficiencies. Alternative distributed and decenteralized payment networks systems can scale better than Bitcoin simply because there can be more of them, or they can potentially scale better because they are less secure (e.g. one using guy fawkes signatures), or because they are less decenteralized. Arguably the latter two are harmful, but better that harm happen on a smaller scale than the whole world and the whole currency. If the economics of scaling create some centralization I would much rather it be in secondary systems than in Bitcoin itself. E.g. if to scale to support all soda-pop transactions centralization must be employed to achieve information hiding, I'd much rather have it in secondary system so that _something_ remained decentralized— that there could be choices in centralized systems— and so that people could insist on those systems prove ownership of their backing Bitcoin. If directly scaling bitcoin creates effective centralization there we would have one-centralized-system to rule them all, and proofs of backing would be not worthwhile. Compromising in bitcoin itself would be strictly inferior— better to compartmentalize the compromise if any must exist at all. Nothing can be more decentralized than the ultimate backing asset (e.g. using a bitcoin-like blockchain to move around mtgox-USD would have almost no value over mtgox issuing blinded tokens for mtgox-usd and would be much less scalable), and so if Bitcoin is to back anything it should be as decentralized as possible. It's not necessarily the case that transaction fees are the only way They are— however— the way we signed up for. And so far, no one has yet suggested something else that would obviously work (e.g. the POS stuff is all sadly broken because as Amiller has aptly put "In proof of stake, nothing is actually at stake") much less would be an uncontroversial replacement for what Satoshi created. Moreover, I'd like to point out that even if a controversial change were technically successful, that success would be potenitally its undoing because it would ultimately erode trust. It would be better for cryptocurrency in general if the succession of incompatible rules were to take place through natural market adoption of alternatives, rather than through a hard-forking change over which there existed any real controversy. ... simply because there is no property right concern when people freely choose to use one system over another, as there may be when a system is, arguably, changed out "from under" people and potentially against their will. (The migration from one cryptocurrency to another is potentially undermining too— 'why adopt foocoin when barcoin will just replace it later?'... but it's potentially less undermining then 'why adopt foocoin when the technorati may change out from under me in the future?'. Considering that Bitcoin's 'competition' is other pure monies backed by the fickle whims of (very powerful) populations and institutions, we must be especially mindful of this.).
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2013, 01:15:47 PM |
|
It's not necessarily the case that transaction fees are the only way They are— however— the way we signed up for.[/quote]I signed up for a currency with a predetermined, limited supply and a lack of a mechanism to enforce prior restraint, not guaranteed profits for any particular person or group of people. If Satoshi thought that transaction fees would be how mining supported itself, that was just a guess. He couldn't possibly have known how it would eventually work out or even thought he could know. Note that some of his other guesses have proved wrong, like the popularity of sending directly to IP addresses. Right now it makes sense to limit the growth of the blockchain while the network is still young, to prevent spammers from overloading it, but restricting the block size in the long term for the exclusive purpose of keeping transaction fees high is a form of central planning. If artificially restricting supply in order to manipulate prices worked to create a healthy economy, there wouldn't be so many people trying to leave managed economies for Bitcoin.
|
|
|
|
FreeMoney
Legendary
Offline
Activity: 1246
Merit: 1016
Strength in numbers
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2013, 02:29:37 PM |
|
No matter how decentralized it remains, Bitcoin doesn't provide any security at all if it's not used, and if 99.99% of transactions must pass through other (probably centralized) networks due to block size limits how much security is Bitcoin actually providing in real terms?
The primary novel thing Bitcoin provides relative to other systems is inflation resistance. It's fairly straight forward show that a system denominated in Bitcoin is actually backed by control over the Bitcoin value they claim to control. (e.g. for example— if you have a distributed payment network based on blinded tokens, you just re-blind and publish all the the tokens, and then publish signmessages with keys in the bitcoin chain for all the coin in the system. Anyone with a token can verify their their token is in the list... and anyone can sum the tokens and see that there aren't more tokens than coins ('anyone' in these cases really just being auditing built into the software that runs randomly and publishes alerts if a discrepency is found)) You're adding the centralized requirement there— but it isn't needed, distributed and decentralized systems denominated in Bitcoin can be created— though centralization does allow certain efficiencies. Alternative distributed and decenteralized payment networks systems can scale better than Bitcoin simply because there can be more of them, or they can potentially scale better because they are less secure (e.g. one using guy fawkes signatures), or because they are less decenteralized. Arguably the latter two are harmful, but better that harm happen on a smaller scale than the whole world and the whole currency. If the economics of scaling create some centralization I would much rather it be in secondary systems than in Bitcoin itself. E.g. if to scale to support all soda-pop transactions centralization must be employed to achieve information hiding, I'd much rather have it in secondary system so that _something_ remained decentralized— that there could be choices in centralized systems— and so that people could insist on those systems prove ownership of their backing Bitcoin. If directly scaling bitcoin creates effective centralization there we would have one-centralized-system to rule them all, and proofs of backing would be not worthwhile. Compromising in bitcoin itself would be strictly inferior— better to compartmentalize the compromise if any must exist at all. Nothing can be more decentralized than the ultimate backing asset (e.g. using a bitcoin-like blockchain to move around mtgox-USD would have almost no value over mtgox issuing blinded tokens for mtgox-usd and would be much less scalable), and so if Bitcoin is to back anything it should be as decentralized as possible. It's not necessarily the case that transaction fees are the only way They are— however— the way we signed up for. And so far, no one has yet suggested something else that would obviously work (e.g. the POS stuff is all sadly broken because as Amiller has aptly put "In proof of stake, nothing is actually at stake") much less would be an uncontroversial replacement for what Satoshi created. Moreover, I'd like to point out that even if a controversial change were technically successful, that success would be potenitally its undoing because it would ultimately erode trust. It would be better for cryptocurrency in general if the succession of incompatible rules were to take place through natural market adoption of alternatives, rather than through a hard-forking change over which there existed any real controversy. ... simply because there is no property right concern when people freely choose to use one system over another, as there may be when a system is, arguably, changed out "from under" people and potentially against their will. (The migration from one cryptocurrency to another is potentially undermining too— 'why adopt foocoin when barcoin will just replace it later?'... but it's potentially less undermining then 'why adopt foocoin when the technorati may change out from under me in the future?'. Considering that Bitcoin's 'competition' is other pure monies backed by the fickle whims of (very powerful) populations and institutions, we must be especially mindful of this.). Hear, hear.
|
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
|
|
|
dree12
Legendary
Offline
Activity: 1246
Merit: 1077
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2013, 02:34:22 PM Last edit: January 01, 2013, 09:17:51 PM by dree12 |
|
It's not necessarily the case that transaction fees are the only way
They are— however— the way we signed up for. I signed up for a currency with a predetermined, limited supply and a lack of a mechanism to enforce prior restraint, not guaranteed profits for any particular person or group of people. If Satoshi thought that transaction fees would be how mining supported itself, that was just a guess. He couldn't possibly have known how it would eventually work out or even thought he could know. Note that some of his other guesses have proved wrong, like the popularity of sending directly to IP addresses. Right now it makes sense to limit the growth of the blockchain while the network is still young, to prevent spammers from overloading it, but restricting the block size in the long term for the exclusive purpose of keeping transaction fees high is a form of central planning. If artificially restricting supply in order to manipulate prices worked to create a healthy economy, there wouldn't be so many people trying to leave managed economies for Bitcoin. At the risk of attracting further controversy, I have suggested that block size limits scale automatically with difficulty, so as to keep up with improving computers. In fact, a decentralized block size limit system should be possible if the network assigns a block weight that decreases with size.
|
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1129
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2013, 03:55:18 PM |
|
Actually Satoshi always intended the block size limit to be raised. I queried the size once (as part of a longer conversation about scalability) and he said this: A higher limit can be phased in once we have actual use closer to the limit and make sure it's working OK. But that's it. He didn't elaborate on how he imagined it being phased in or what "working OK" meant. Satoshis view was always that Bitcoin could scale up more or less forever. I was quite skeptical back then, but I came around to his way of thinking with time. gmaxwells point about the relationship between block size limits and fees is valid, if you agree with the following statement: There _must_ be competition for block space to make fees a viable way to pay for security. However not everyone does agree with it. For instance, I believe that coalitions of entities interested in maintaining certain network speeds can and will build network assurance contracts (contracts that spend all their inputs to fees), thus funding the public good of security. I don't think competition for entering blocks is the right funding model. Fortunately, there are ways to resolve these debates amicably. For now of course we can just ignore it. We're not close to reaching the block size limit nor are we close to losing inflation as a funding source. Later on, we can use the usual mechanism for phasing in rule changes - have new block or transaction version numbers express acceptance of the new rule set and automatically begin enforcing them if/when more than a certain percentage of users have opted in (probably a very high percentage). I think these debates will gain clarity once inflation falls again and we start seeing merchants losing money with some degree of regularity, due to double spends. If assurance contracts are going to work, it'd make sense that we find out at that time. If it's shown that they can work, a lot of the arguments for small block sizes go away (especially with software that scales much better).
|
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1129
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2013, 03:56:17 PM |
|
Mike, do you know if Bloom filter support is intended for the Bitcoin 0.8 release or after that?
I'm hoping we can get it into 0.8 - it just adds new features so unless the new commands are exploitable somehow, there's no real risk. If there any serious bugs are found we just delay the rollout on the bitcoinj side until things are resolved.
|
|
|
|
Stephen Gornick
Legendary
Offline
Activity: 2506
Merit: 1010
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2013, 07:57:13 PM |
|
We're not close to reaching the block size limit
You and I have differing opinions on what "close" is then. Here are the last 10 blocks: 214657 48.711 214656 31.016 214655 133.286 214654 261.695 214653 15.265 214652 42.617 214651 36.039 214650 204.577 214649 3.489 214648 214.828 The average for these is about 100K. And it appears to be approaching the rate of 300 transactions per block (about 43K transactions per-day). - http://blockchain.info/charts/n-transactions-per-block?timespan=180days&daysAverageString=7This is a transaction every two seconds. A lot of these are microtransactions (e.g., under a dollar's worth of coins) used for wagering, so the blockchain already has a way of limiting those: If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc.
- http://en.bitcoin.it/wiki/Transaction_feesBut twelve months ago no SatoshiDICE existed and nobody knows what 2013's breakaway Bitcoin success story will be but what if there are four of them, each as popular as SatoshiDICE is today. Then the blockchain size limit (at the current restrictions) will be reached.
|
|
|
|
Kluge (OP)
Donator
Legendary
Offline
Activity: 1218
Merit: 1015
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2013, 08:10:12 PM |
|
I cannot run Bitcoin-qt during the day because I'm on a tethered 3g connection and do actually need to use most of the available 5-150kbps of bandwidth during the day. The absolute maximum long term average bandwidth pulling the blockchain can take is about 13.3kbps/sec. I'm not sure what the source of your issues is— it may be due to bandwidth used relaying blocks and transactions to other peers, but you do have enough bandwidth to stay synchronized— at least to within a couple blocks of most current. That said, for a mobile connection— a thin or lite client is the obvious thing to use. Ideally, you could run one behind a full node that you have absolute trust over (E.g. because you own it), and then you don't even need to worry about the potentially reduced trust model involved. But it would still be interesting to figure out why your node isn't keeping up. I frequently forget to load up -qt when I go to sleep, but can't run it during the day because I have other things to do on multiple computers and am too lazy to run back and forth from office to shut -qt off whenever I'm looking for something online. If I used a program like NetLimiter, now having a figure on how much -qt should require to keep blockchain updated, I could probably just limit the amount of bandwidth bitcoin-qt uses, keeping it to maybe 10kbps during the day, unlimited at night, and still stay at or close to current with the blockchain. If you really need an answer on how I can't keep up..... ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) At night, -qt is also competing with programs including Skype (which sucks down ~50MB/day), Chrome (usually with auto-updating pages like Gmail because I forget to shut them off), and a miner (consuming 25MB/day more). Chrome varies, but probably consumes roughly 10MB at night. Combined at night, then, assuming 10pm-8am, programs other than -qt consume ~41.25MB over 10 hours, which'd work out to be 4.125MB/h, .06875MB/m, ~9.2kbps. -qt runs only during those 10 hours (when I remember), so for the sake of quick, rough guesstimates, I'll say it has 7.5 hours to run. It was claimed above that blocks are currently ~10% full. I'm not sure how exactly that'd translate to kbps, but I'll just assume it's ~10% of 13.3kbps. So, -qt should then consume only ~1.33kbps. Multiply by 3.2 (24/7.5) and you get 4.256kbps to run -qt from 10pm-8am and keep up with the blockchain. In total, I should be consuming ~13.456kbps at night. But then you have to take service outages into account, which vary widely in times per day, and duration, but it's safe to say my service is out >20% of the time, the ">" being what I'll trade for the bandwidth the miner, Gmail, and Skype won't be utilizing at full capacity. So now the effective rate I need my Internet connection to be at night is ~16.1472kbps. My connection varies wildly, but if I had to take a guess based on MB/day I consume from logs, assuming I'm utilizing the max amount of bandwidth all the time, I have something along the lines of 31kbps on average (almost as fast as dial-up!), a bit under 2x what's required. Though, you could've ignored everything I wrote in this paragraph since you'd only need to read that I start "large" (5MB+) downloads at night. No guarantees on the math, but that should be about where I'm at. Glad to see such an in-depth discussion. Thanks for everyone's response.
|
|
|
|
|