Topic: SatoshiDice, lack of remedies, and poor ISP options are pushing me toward "Lite" - page 3. (Read 7374 times)

S.DICE spam is just a prelude. 
It sure starts to sound like that we are circling back to what we are running away from - central control by few large entities. I guess we must be blindfolded and our imaginary straight line away from here, takes us back where we started.
Few huge mining farms will become the new "central banks" or "FED", if I may, and nothing has really changed. They will control the fees, the software features, protocol etc. BTC will be really convenient to use and it's accepted widely, but we as a community, have no vote/controll/etc over it. You win some, you lose some
Small guy is kicked out of the mining picture, bloated blockchain requires absurd amount of space and user will never ever download the full bc. Nobody really knows, is the existing BC the correct one or not. Only "Banks" know and you can be probably wiped out financially or blocked to use your funds as you are now.

Time to get over this childish "Staoshi knows everything" hysteria and start thinking about the worst outcomes and how to avoid it.

Except you didn't actually substantiate your claim.

Exactly.

Bitcoin is fundamentally not very good as a payment network. Global visibility is not compatible with high scalability and the security global-visibility provides somewhat unnecessary for pretty much anything short of the inflation resistance of the system... 99.999999% of the world does not care about the security of every dumpling bought in china. The nature of Bitcoin makes many worthwhile mechanisms like anti-fraud and instant fairly-firm resistance to reversal hard or impossible without attentional layers.  Bitcoin needs to be something of a payment network to be useful at all and the better of one that it is the less costly payment networks will and must be, so it's desirable to make it the best it can be— but it's not worthwhile to compromise the unique values that make it worth having, since no amount of compromise can free you from payment networks.

I think if more of the effort spent speculating on likely impossible modifications to Bitcoin itself (I don't mean the block size stuff as much as stuff like demurrage) was spent on inventing decentralized payment infrastructure we'd make a lot more progress. Remember, that one of the attractions of Bitcoin is that there is no centeral bank telling you that you can't invent new payment systems.  Bitcoin has solved the hard part in this ecosystem: invent a purely decentralized digital asset which people will recognize as valuable. Now interested parties can go figure out how to optimally exchange it with others.  Plus, when building a new system you're free to design in whatever features you think are important without being called a thief, and the public is free to choose not to use it. Bitcoin gives you an existing cryptocurrency ecosystem so getting value into it at all isn't a problem. Win win win. 

It makes me sad that in so many technology discussions people penalize things for being more flexible.  Were it possible for bitcoin to be usable with no payment network functionality at all it would still be awesome.  It seems when something can do five different things all the 'experts' on the Internet think it's appropriate to demand that it be the absolute best at each thing and that it sucks if it isn't. Sorry kids: Real engineering is all about compromises.

I think it is agreed that most Bitcoin payments won't take place on the blockchain. e.g., with tx replacement you can have one transaction carry multiple payments, and there can be various 3rd party services (I'm using "various" in a mostly positive sense - Bitcoin enables possibilities with good tradeoffs, better than the current banking system) . So 1B daily payments doesn't mean 1B daily transactions. The more transactions can actually make it to the blockchain, the lesser the overall "tax" (in the broadest sense) of using additional layers.

It's doubtful that anyone will be able to hold the entire blockchain at some point in the future, should Bitcoin become a mainstream thing.

Here's some interesting data (from 2006 only for the US)

Average daily number of transactions:
- 60 Million credit card transactions
- 100 Million Interbank ATM transactions
- 60 Million ACH transactions
- 15 Million SWIFT transactions
- 365.000 CHIPS transactions
- 521.000 FEDwire transactions
- 700.000 CLS transactions

So that's a cool 237 Million daily transactions, in the US alone, excluding cash transactions.

Let's assume a conservative average of 3 daily cash transactions per person (buying the paper, a hotdog and a pack of smokes). That adds a cool 1000 Million transactions for the US alone right there.

Yeah. Better go grab a YottaByte HD real quick.

That's a terrible way of deciding an important issue such as this. Miners are not a very important part of the Bitcoin economy, and they don't have much more understanding of Bitcoin than anyone else. Their "votes" shouldn't matter more than anyone else's. (There shouldn't be general voting at all, in fact -- democracy is a poor way of making decisions.)


The block size limit doesn't need to be centrally-determined. Each node could automatically set its max block size to a calculated value based on disk space and bandwidth: "I have 100 GB disk space available, 10 MB per 10 minutes download speed and 1 MB per 10 minutes upload speed, so I'll stop relaying blocks [discouraging them] if they're near 1/8 MB [enough for each peer] and stop accepting them at all if they're over 2MB because I'd run out of disk space in less than a year at that rate". If Bitcoin ends up rejecting a long chain due to its max block size, it can ask the user whether he wants to switch to a lightweight mode.

Users could also specify target difficulty levels that they'd like the network to have and reduce their max block size when the network's actual difficulty level drops below that. A default target difficulty level could maybe be calculated based on how fast the user's computer is -- as users' computers get faster, you'd expect mining to also get faster.

I don't see how this makes any sense at all without making additional assumptions which would make Bitcoin pointless. The stochastic nature of mining means that there is always large uncertainty about block delivery times— the block gap is frequently anywhere in an hour window.  Paying non-trivial amounts for trivially copyable data to get it seconds faster when the common arrival uncertainty was already an hour does not generally make sense for most applications.

Keep in mind that a little payment isn't sufficient, mining needs to be expensive enough that an attacker can't do a short term attack— doubly so in the future because there will no subsidy motivation for honest behavior anymore, the motivation to behave honestly would be fees and preserving their value— Without the proof of work Bitcoin is just a particularly computationally and bandwidth expensive rumoring network totally vulnerable to network attackers.

You might be assuming that the miners would keep blocks secret from parties that don't pay them, but this can only be done if mining is centralized since otherwise a miner who promotes their block further faster gets built on and they become the valid block.  Moreover, block secrecy violates the less discussed second half of the Bitcoin security assumption:  Bitcoin assumes that honest parties control a majority of the mining applied computing power _and_ that information is easy to spread and hard to stifle.  The latter part is critical because you can only converge on the longest chain if you've actually heard of it. We don't talk about it much because it's not hard to meet today and you have bigger problems if you can't even get the blocks... but it really precludes any kind of paid access to blocks from being viable.

As far as the OP's issue— it would be pretty easy to add a trickle mode to the client where it only connects to the network periodically and only fetches blocks just to avoid failing behind. So you'd leave it running... but it would only connect to a few peers on the network ever half hour or so, pull new blocks and disconnect, then process them slowly and unintrusively. But I don't think there is enough demand for such a thing to bother coding and testing it.  Maybe that sort of thing could become the default behavior for minimized gui full nodes that aren't listening, but I dunno— differences in behavior create confusion.

My back of the envelope calculations suggest this is a likely possibility.

(emphasis mine)

As computing times shrink, I expect big miners will be paid by big corporations and banks to directly deliver new blocks to them, bypassing the network and its latency. This is an example of an external incentive.

Not quite.  Once the initial block reward is exhausted (negligible), fees are the only mining income.  So that leaves only two possibilities:  transaction fees would be how mining supported itself, or external incentives cause miners to mine at a loss (fee-wise).

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

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=7

This 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:

- http://en.bitcoin.it/wiki/Transaction_fees

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

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.

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:


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:


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

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.

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.

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.

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

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?