Topic: Funding of network security with infinite block sizes - page 7. (Read 24528 times)

Mike, lets suppose for a second that I am correct, and Tor bandwidth and other anonymity technologies do not scale with the bandwidth possible at VPN/co-location providers, and thus running mining (not hashing) operations is not possible anonymously.

What do you expect to happen?

I think you are massively over-estimating the difficulty of mining anonymously (as is usual with these debates).

Firstly, there is no particular reason mining on a pool requires a lot of bandwidth. Stratum with high difficulty shares already cut bandwidth usage very low.

For running the full node/pool itself, resource requirements are low. You can connect to the P2P network to gather transactions just like any other client. Nobody knows you are mining, even without Tor, as your behaviour is indistinguishable from any other node. Nodes can synchronise their mempools are startup and then know what each peers preferred block contents is likely to be: once solved, a block can be transmitted as a delta against the expected contents. This has the side effect of increasing bandwidth requirements for people who want to mine empty blocks, which is satisfying.

However, even without that change, I can't see a time when mining anonymously is impossible. Your argument, as always, relies on the assumption that "things" cannot possibly scale up, where the thing here is Tor. Tor can scale, so even if mining ends up requiring a lot of bandwidth it doesn't change anything.

Honestly Peter, to be blunt I long ago concluded you're just working backwards from your preferred outcome. You don't want Bitcoin to scale up, and you will continue to invent ever more convoluted and baseless theories as to why it can't, until the end of time. Convincing you doesn't seem to be possible.

"God damn it, why won't that 5% of miners stop putting '1MB' in their coinbases. They're holding up progress!

Fine, lets just block those stuck pigs, we're not colluding or anything."


"FinCEN: From now on miners are money transmitters and must report all unusual transactions.

FinCEN: From now on miners must not mine transactions over xBTC if they satisfy the criteria of unusual.

FinCEN: From now on miners must also not build upon blocks that have transactions that they themselves would not be able to mine due to our regulations."

VPN's and offshore jurisdiction are irrelevant in this scenario - Bitcoin hasn't been banned so we can fully expect mining pools to stay in the US and other visible, regulated, countries to take advantage of the cheap high-bandwidth internet connections required to run a pool.

tl;dr: Don't be naive.

That requires collusion, though, just like a 51% attack. Any attacker that can convince a significant percentage of miners to behave a certain way can disrupt Bitcoin. That happened recently when Gavin played the role of attacker and convinced enough miners to introduce forking software (aka version 0.8 ).


I don't see how you get that. Not that I have anything to do with Silk Road but I, for example, have wallet addresses that can't be linked to me in any possible way, no matter how much you analyze block-chain info. Regulating miners can't change that.

It's impossible to ask for a significant minority of 'no' votes to be your decision point, because a majority of 'yes' votes can decide to only mine on top of blocks that do not vote 'no'

All you can measure is a majority either way.


On-chain have some privacy, and privacy that can be taken away by regulating miners. Off-chain with chaum tokens can have mathematically provable privacy simply unattainable by on-chain transactions.

I don't believe that would work, at least not any more than an attacker doing the same thing to engineer a 51% attack. It doesn't work by amassing enough 'yes' votes (it's assumed resourceful miners always want an increase). Rather it polls to see if there are significant 'no' votes.


Really? I wouldn't think so considering the success of Silk Road.

...which means an attacker has strong incentives to buy, rent, or coerce hashing power to vote for a blocksize increase. For instance in FinCEN was devious, part of regulating mining would be forcing miners to vote for a blocksize increase; inherently on-chain transactions vs. off-chain meet their goals of financial transparency and restricting privacy. Or this may be something as subtle as funneling money to tx fees for lots of low-value tx's, perhaps with unspendable but non-prunable outputs to further increase the cost of running a mining node well into the future.

Fundamentally miners are not representative of Bitcoin and the choice of what the blocksize needs to be must not be under their control.

Well, that works under my proposed solution, which is a dynamic cap that increases only if there isn't significant objection from the field of miners to an increase. That way as more bandwidth becomes available in the future, even for Tor users, the cap can be raised as opposition to increased size would die down.

At worst FinCEN would just drive the pool operators to operate outside the US and business as usual would continue, with US-based pool members routing their connections through VPNs.

Note how the recent run-up in price, and in particular the media coverage about it, has been focusing on Bitcoin as a store of value rather than Bitcoin as a payment system. The media has correctly identified what makes Bitcoin truly special, and it's not by being a irrevocable version of PayPal.

We're an order of magnitude away from filling up blocks without crowding out the low-value stuff yet at all, and rudimentary off-chain transaction stuff already exists in multiple forms. At the same time it's clear that FinCEN may in the future decide to regulate mining directly, so the arguments to keep the blocksize small to allow for anonymous mining are clearly valid; even 1MB blocks are a bit marginal with Tor.

Guys we really need some semblance of a solution forming. I have a feeling it will get far more crowded around here soon.


http://www.cnbc.com/id/100609853

I'm thinking the middle ground between cap and unlimited size (i.e. dynamic cap) is our best hope.

Exactly. It's the law of diminishing returns - all the best paying transactions will be in the first 1MB.

--> As long as there is users paying the fees for it.

Also, Mike Hearn posted many topics about bitcoin control with blacklisted addresses and tainted coins, all depending upon miners centralization.
This is another reason I would prefer a pressure to keep everything as small as possible.

Suppose we have huge miners imposing themselves 5-10x more difficulties than the minimum required by the network. They will make more money, but at the same time the smaller miners can choose to let go the superfluous transactions (and their fees) in exchange of a higher probability to solve the next block. It's like the pools fee: some are OK with getting less money as long as it's more consistent.

Lateral thinking is always welcome, but any change which makes you think "hmm. That could have unintended consequences..." requires a great deal of analysis and prototyping before getting near live.


Plan A: simple increase of block size limit based upon median size of recent blocks (or similar approach)
Plan B: optimal block sizing algorithm OR infinite size allowed. Either case with whatever incentives are determined to work.

Have plan A ready for a new release, at least by the time 500KB blocks are common. Plan B can simmer in the background until a version is demonstrably better than the simple plan A implementation. Only then do it.

Maybe, though, if you make it so that you get super-linear reward for linear effort, then everyone will try to make their blocks as large as possible.

Agreed, the block reward incentive drives solely hash-power, whereas the fees-only regime (after circa 2040) is expected to incentivise both hash-power and tx storage. The phase we are entering now will be the gradual transition between the two regimes for approx. the next 25 years.

Maybe an interim solution for an interim situation?

Mike, sorry to derail this thread some but creating multiple threads on the same general subject seems unhelpful  

I've finally had time to consider assurance contracts. The idea is good (e.g. Kickstarter) but it won't work IMO for Bitcoin.

The reason stems from something you pointed out and which I mentioned elsewhere: transactions come in different types. Often in block size discussions we refer to transactions quite generically - we view them only in the sense of data. However, transactions are not created equally. You correctly note some transactions can happily wait days for clearance and others, like micropayments, are not concerned much with double spends.

This line of thinking led me to realize the block size issue should be easily solvable. I'll get to that in a second. The reason assurance contracts won't work for Bitcoin is the participants you imagine might form such contracts won't opt for an inefficient payment channel.


If I'm a dentist or coffee shop proprietor why would I be using the block-chain for transactions? As you note it's subject to double spends, and at the very least unpredictable payment confirmation delay which can stretch well over an hour.

As I've posted often before I see Bitcoin transactions evolving to be handled largely off-chain. Native Bitcoin is not ideal for the majority of the world's transactions and never will be. If I'm a legitimate lawful business I care little about anonymous payments and irreversibility for clients. I'd just as soon use "BitcoinPal" to accept bitcoins instantly. If I'd pledge money for an assurance contract I'd certainly offer it to an entrepreneur that could offer a more elegant and professional payment solution.

So the block size issue should be easy to solve. We'll never need an infinite block size to ensure Bitcoin can handle the world's transactions. The majority of these will prefer not to route through Bitcoin. So why are we insisting they be able to?

Instead, all we need to achieve is usability for those transactions which uniquely value native Bitcoin. Such transactions (like those of Silk Road) should have little problem paying a decent sized fee for the value the block-chain provides. This solves DOS attacks for trivial fee amounts and other block-chain spam from low value transactions.

As I describe above we should allow the cap to be dynamically set by polling miners every so often to see when they are comfortable - even those of lower resources - with a higher block size limit. This prevents formation of mining monopolies while allowing Bitcoin to scale with technological progess.

OK, so it doesn't work if you pick those particular numbers. How about if doubling the difficulty gave you 4x the space then? Or more?

Only if by "many" you mean less than two.

http://blockchain.info/charts/transaction-fees?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=1&address=

That actually effectively illustrates part of the difficulty in creating a solution:  our economic reasoning will be clouded for many years by the block subsidy, which will probably dwarf the transaction fees for years to come.  Efficiencies which must exist in the self-supporting, fee-only future are unseen at this time.