Topic: How a floating blocksize limit inevitably leads towards centralization - page 4. (Read 71590 times)

That's quite literally the intent of the send-to-many transaction type, although it's much more likely that they'll be used to send to pay many different vendors from one single payer than multiple payers to multiple payees.  The best example is that of weekly payroll, as anyone getting payed wages in bitcoin, working for the same company or entity, can be paid their weekly wages in the transaction as everyone else.  Regular users could do the same thing using bitcoin aware bill payment programs, than can gather up all the re-occuring and one time bills that a person has received, and pay their water bill, electric bill and cable bill, etc. in a single action; so long as they have the total value in inputs that would be required.

So while a direct deposit payroll event for any significantly sized company would involved hundreds to thousands of electronic transactions per week, these same companies could do the entire event in a single send-to-many transaction that weighs in at a couple kilobytes, and currently should cost less than a quarter.  Even if the transaction cost rise that such a large transaction costs $10 at a time, that's chump change compared to the costs of simply printing cheques, much less mailing them.  In the event that small value transactions wherein the customer sends the vendor a set of low value keypairs (as opposed to transactions), the vendor would have a vested interest in flushing those keypairs in a timely manner, so as to limit the risk of a double spending fraud against them.  In this way, collecting those many inputs and pumping them back out to employees with the weekly payroll send-to-many transaction does double duty.

No, no, no. I am the last person to advocate jumping straight to 10Mb.

What I think we need is a flexible limit along the lines of the many suggestions which attempt to take account of what we know to be important, especially encouraging fees and eliminating free micro-transactions. Perhaps it should also adapt to block propagation times, constraining the limit if network performance degrades too much.  I appreciate that it is impossible to get this perfect on the first attempt and agreement on the detail may take time.

So a two step plan seems best:

1. In the next version the limit constant becomes a variable that increases 20% if the average block within the previous difficulty period is >80% of the limit (or a simple variation of this).

2. In a subsequent version activate the best adaptive/algorithmic block limit strategy which has found a consensus.

The advantage of step 1 is that it gets an early solution into the field achieving huge risk mitigation. It will have more time to be adopted by the greatest number of nodes. Step 2 is the attempt at a permanent solution  which may happen even before step 1 has its first automatic increase, or it could be delayed for a year through analysis paralysis - it won't matter as much either way.

Okay, but is jumping directly to ten megabytes in one fell swoop the best way to go, instead of , for example, a series of doublings?

-MarkM-

Fine, here you have the definition of a transaction unit. Of course I understand that there are multiple inputs/outputs possible, which makes bitcoin transfers much more efficient than in conventional payment systems. I was just using terminology common on sites such as blockchain.info. This makes 4 tx/s a valid description of the real-world situation.

It is no good having theoretical efficiency available if it is not being physically used! You say it could be used, and this is true, however optimum transaction efficiency cannot be achieved by a wide user-base overnight. My concern all along is that bitcoin usage is growing exponentially, at a much faster rate than the adoption of transaction efficiency, or complimentary off-chain solutions are appearing.

There are a lot of smart people on this forum who fully understand exponential growth curves. Yet it seems some of these people think that a hard limit can seamlessly force adoption of efficiencies and complementary solutions which are developing linearly in comparison. 

There can be no seamless transition in that scenario, which is why an adaptive/algorithmic block size limit is needed sooner than later.

Alt-Ripples!

Consensus ledger without (proof of) work!

-MarkM-

At the end of the day, the basis for proof-of-work is harden the ledger so the concept of 'cost-free' is not really that big a deal (to me.)  In some ways it is pretty compelling that all of the mining effort in the world benefits by working for all block chains.  Kind of a win-win.

On the other hand, if various block chains became compatible in size to one another, or could form coalitions and display an adversarial posture, there will likely be attacks.  It makes economic sense and certainly it (resource conflicts) are more commonly observed in nature than not once a carrying capacity is approached.

I suspect that in the end a solution which relies exclusively on simple size dominance will be overcome.  But there are a lot of other possibilities I bet.

You could have a standard that all chains comply with.  This would allow interoperability.  Atm, that means compatibility with the bitcoin chain.

However, the merge mining against the bitcoin chain means embedding information in the coinbase transactions.

A header made specifically for merge mining would be much more efficient for the alt chains.

For example, you could have a hash-header of the form

var_int: nonce
byte[32]: merkle root

This isn't even really a chain.  You create a header of that form and the roots of the merkle tree are what you are trying to stamp.

The alt chain's header would then be

byte[32]: previous block
byte[X]: message
var_int: difficulty
var_int: nonce
byte[32]: merkle root
byte[N][32]: path from root to hash(previous block + message)

Having said that merged mining means that you are generating more proof of work than you actually performed.  It is feels like forged proof of work.

An alt chain could end up being overwhelmed by "cost-free" proof of work from other chains.  It makes it possible to "stamp" alternative block headers for no margin cost.

Maybe having the world's most difficult proof of work also leads to centralisation, as my primary motivation for running a full *bitcoin* node is to use bitcoin, via p2pool, to secure other chains.

Is there a way of merged mining without having to "centralise" the chains to be merged-mined all at one site where the possibly to be massively bloated bitcoin chain is also to be found?

Maybe even think ahead that if bitcoin is to become some bloated monstrosity maybe some of the merged mined chains might too, so if the bitcoin chain can be made use of (for merged mining) without having to have a full node of it actually present (piped into the building in all its massive glory so to speak) could one extend that to have maybe some space between each massively bloated chain of a merge and the nice compact collection of however many much smaller chains all of which can all easily be handled at once at one Joe Sixpack's desk?

-MarkM-

Lazy miners are always lazy. They won't verify no matter the block size is 1kB, 1MB or 1GB. So your reply is irrelevant to the OP.

With trusted full node, people with insufficient resources will still be able to run partial nodes, which will also protect the integrity of the blockchain. I don't think these will be provided by pools. They could be supported by donation or big exchanges. Also, it could be run by trusted Chaum banks (https://bitcointalksearch.org/topic/fidelity-bonded-banks-decentralized-auditable-private-off-chain-payments-146307), as they have to run full nodes on trusted platforms anyway.

Technically speaking, that's a very clever idea.

Socially speaking though, it'll be an utter failure. Miners using pool have absolutely no incentive at all to verify the blocks they produce other than some vague desire to protect Bitcoin. This is why currently pools other than P2Pool aren't verified at all - Eligius supports getblocktemplate, but mining software that uses a full validating node to verify the blocks is hardware ever used.

Pools just aren't going to buy a bunch of expensive trusted computing hardware and switch their operations to use fragile trusted computing software just to please the 1% of miners who seem to care about this issue.

retep thanks for making the picture even clearer. It's good that there's talk about concrete examples instead of theoretical maximums or minimums.

Those numbers are bogus and show very little understanding on the part of solex.

The problem is apparent if you look at transaction 3e4116059a0edb1134126047d9e5ebfa1619b6180153cdc8390e6e36c375a179 from block #259156, one of the blocks in solex's analysis. That transaction has one input, and 41 outputs. Now for the purposes of determining how many transactions Bitcoin can perform per second, are you going to count it as one transaction, or more than one? solex is counting it as one.

As transactions become more expensive per byte people are going to use all sorts of techniques to make transaction size smaller. For instance you can combine transactions together with other parties; each transaction includes a 10 byte header. If you get together with 20 other people, you've saved 200 bytes and you improve your privacy because you've mixed your funds with those 20 other people.

The absolute minimum transaction size(1) is for single input single-output transactions. They are 192 bytes each, 182 if transaction combining is aggressively used. 1MiB/10minutes * 182bytes = 9.6tx/s

Big eWallets services like instawallet will be able to get much closer to that theoretical limit than other services simply because they'll have a wider range of txouts to chose from. We may even see agreements between services to use each others wallets just to optimize fees, with something like ripple used to settle imbalances periodically; if off-chain transactions become supported, it's quite possible even day-to-day users will be running software that does stuff like that automatically.

1) Minimum signed transaction that is. The technical minimum is 60 bytes, but such transactions are spendable by anyone and thus offer no security.

With full nodes building on trusted computing platform, miners with low bandwidth can mine without being full nodes themselves.

In addition to working as a normal full node, a trusted computing full node will accept encrypted queries and reply with encryption, so the operator is unable to censor. It will also prepare a list of all unconfirmed valid transactions, including only the txid, size, fee (and optionally tx priority). The list will propagate in a P2P manner. Miners will construct blocks by choosing the transactions they want to include, in addition to coinbase and any other valid tx not provided by the trusted full node.

To prevent the node from cheating (not very possible due to trusted computing), individual miner will fully validate some blocks regularly, depending on their resources. For a miner with only 50kB/s connection (i.e. 30MB/10min) while maxblocksize is 300MB, he may validate only 1 in 10 blocks.

The trusted full nodes will be supported by donation and/or subscription fee. People with many bitcoins will support/offer these nodes to protect their wealth.

Yes, and the lower chains would almost certainly be merge minded.  They would have their own proof of work totals.  It would be worth making this easier.

The objective of the proposal was to keep things tracked by a single main/root parent chain.

The proof of work is separate, if you trust the root chain, you can trust the lower chains (but less so as you move downwards).

Having alt chains means exchange rate risk.  Ofc, my suggestion also has some exchange rate risk, if one of the chains is badly verified, but somehow survives for 120 confirmations.

And severe focus on trivial transactions worth less that it cost to make them possible in the first place also might limit the economy.

If it comes down to transacting houses and cars or lollipops and chewing gum lets throw some lollipops and chewing gum in the glove compartments and pantries and stick to transacting cars and houses.

There IS anyway some direct relation: not enough total value of all 21 million coins means not enough miner savings to buy better infrastructure. So I challenge your assertion or want to see the formula known as "no direct".

Halve the exchange rate and you halve, directly, miners' capital savings.

Divide exchange rate by ten and you decimate the liquid production-capital of the economy.

Multiply it by ten ... would that multiply the liquid production-capital of the economy? By how much?

-MarkM-

The BTCt fiat exchange rates have no direct influence on the transaction rate.  Only the size of the economy has a real influence on the transaction rate, but severe limitations on the transaction rate might be a limitation on the size of the economy.

Why? What is the proportianality of exchange rates to transaction rates?

Exchange rate is approx. $30 per coin currently at current number of transactions per second. What value of exchange rate will it take to drive transaction rate up to 4 per second?

-MarkM-

That is truly awful news.

Excellent. Someone finally quoted some real numbers instead of theoretical maximums, the picture is a bit clearer now, thanks!

I take that back because these blocks are version 1 and Eligius is supposedly producing all version 2 (http://blockorigin.pfoe.be/top.php)

However, I have extracted the transaction counts and they average 1190 each. Looking at a bunch of blocks maxing out at 250Kb they are in the region of 600 transactions each, which is to be expected. Obviously, there is a block header overhead in all of them. But this does mean that the 1Mb blocks will be saturated when they carry about 2400 transactions. This ignores the fact that some blocks are virtually empty as a few miners seem not to care about including many transactions.

So 2400 transactions per block * 144 blocks per day = 345,600 transactions per day or Bitcoin's maximum sustained throughput is just 4 transactions per second.
This is even more anemic than the oft-quoted 7 tps!