|
Title: Proposals for fast dynamic blocksize Post by: stdset on December 13, 2016, 10:42:55 AM By fast I mean that blocksize should be able to significantly change in matter of at most hours, the faster the better. Size of any particular block even might not directly depend on size of previous blocks.
So here's one proposal by TierNolan: An idea I had about network congestion was that transactions could pre-buy block space. A block size rule of this type would be 10MB per block total size, but all blocks are capped at 1MB "modified" block size too. Normally, a transaction's modified size would just be the size of the transaction. For each output, it can add additional loading. This increases the modified size of that transaction but then decreases the modified size of the spending transaction. A 500 byte transaction could have an output that is loaded at 500 bytes. That transaction would count as a 1000 byte transaction for modified block size purposes. If the output is spent by a 490 byte transaction, then that transaction would count as -10 bytes. Essentially, the transaction's modified size would be actual size + sum(output loading) - sum(input loading) When loading an output, that transaction costs more but then the spending transaction costs less. This means that the channel open transactions could be loaded so that the channel close transactions don't actually use up block space. If there was a lot of congestion miners could still include up to 10MB of channel close transactions per block. The average block size would be 1MB but could be increased by 10X in an emergency. And another, by Meni Rosenfeld (full description is long, so I quoted only tldr): tl; dr: I propose replacing the hard cap on the data size of a block (1MB, 20MB, or whatever it is) with an elastic one, where resistance to larger blocks accumulates progressively. Miners will be required to pay a superlinear penalty for large blocks, to be paid into a rollover fee pool. This will greatly increase Bitcoin's robustness to a situation where the block cap is approached, and allow a healthy fee market. Are you aware of other proposals? Do you see any vulnerabilities? Which proposal do you think is the best? Let's discuss. Title: Re: Proposals for fast dynamic blocksize Post by: Manfred Macx on December 13, 2016, 01:46:58 PM I am not sure I understand TierNolan's proposition. If transaction is 500 bytes big, why does it need extra 500 bytes space? No other transaction in the block can use it. If transaction is 1000 bytes big, but there is only 500 bytes left in the block, the transaction wouldn't have to buy extra space, the miner would just add it if it had a permission to increase the block size above 1MB, and the sender would pay for the whole 1000 bytes.
Also, why does the size of the transaction spending such input matter? What use does anyone have from those remaining 10 bytes (500-490)? Title: Re: Proposals for fast dynamic blocksize Post by: stdset on December 13, 2016, 02:25:52 PM If transaction is 500 bytes big, why does it need extra 500 bytes space? Let's call this tx - tx1, and a subsequent tx, which spends outputs created by tx1 - tx2.There can be situations, when it's very important to get tx2 confirmed in timely manner, for example it can be emergency channel closing tx, or a tx aborting channel opening (in some LN designs). If our channel opening txes prebuy block space like tx1, miners will be free to include closing txes even if blocks are full and there are lots of unconfirmed regular txes. In scenario of mass emergency channels closing (for instance a big hub goes rogue), blocks will effectively increase in size several fold and funds theft will be prevented. At the same time we are still sure that all additional blockspace isn't free. Title: Re: Proposals for fast dynamic blocksize Post by: Manfred Macx on December 14, 2016, 01:04:53 PM Let's call this tx - tx1, and a subsequent tx, which spends outputs created by tx1 - tx2. There can be situations, when it's very important to get tx2 confirmed in timely manner, for example it can be emergency channel closing tx, or a tx aborting channel opening (in some LN designs). If our channel opening txes prebuy block space like tx1, miners will be free to include closing txes even if blocks are full and there are lots of unconfirmed regular txes. In scenario of mass emergency channels closing (for instance a big hub goes rogue), blocks will effectively increase in size several fold and funds theft will be prevented. At the same time we are still sure that all additional blockspace isn't free. Thank you, I understand now. So a transaction would need a new field (or an opcode or something like that) to signal that it is prebuying space. But not for itself but for whatever transaction spends it. And since every transaction needs to pay for space, this should prevent a potential spam attack. But what if tx1 doesn't make it into the block on time? Wouldn't that mean that every transaction in this chain should prebuy space, just in case it doesn't make it into the block? If there is enough space in the block, tx2 will still count as using that extra space it's parent bought, I suppose? Besides if, all transactions in a channel are sent off-chain and only the opening and closing ones are sent on-chain, wouldn't that mean that first we would need to send tx1 to prebuy space, and then tx2 to maybe use that space? We are also still left with an arbitrary 10 MB limit, which may be enough only for a limited amount of time. Title: Re: Proposals for fast dynamic blocksize Post by: stdset on December 14, 2016, 04:08:45 PM But what if tx1 doesn't make it into the block on time? Unlike tx2, tx1 confirmation time isn't critical, if takes longer than we expected, it's just an inconvenience for us at worst. And to make sure it won't take too long we only need to include competitive fee proportional to modified tx size.If there is enough space in the block, tx2 will still count as using that extra space it's parent bought, I suppose? I think so, I'm not sure however, maybe it can be implemented different ways. But even if it counts as using the extra space, that doesn't upset us much. Because what's really important in this case is confirmation time. We only loose fee for that extra space.Besides if, all transactions in a channel are sent off-chain and only the opening and closing ones are sent on-chain, wouldn't that mean that first we would need to send tx1 to prebuy space, and then tx2 to maybe use that space? I'm not sure if understand you here. In level 3 LN (one which needs segwit) it's important that all commitment txes prebuy enough space for certain outputs, so that txes spending those outputs are readily confirmed. If one of channel participants refuses to use space prebuying, it's a red light, another channel participant should immediately close the channel, or abstain from channel opening if it's not opened yet. The opening tx should also prebuy space enough for a commitment tx.We are also still left with an arbitrary 10 MB limit, which may be enough only for a limited amount of time. I think numbers here are completely arbitrary. They can be adjusted according to community consensus on optimal blocksize. Moreover, they can be adjusted by a slow dynamic blocksize algo, if one will ever be adopted.Title: Re: Proposals for fast dynamic blocksize Post by: TierNolan on December 14, 2016, 05:39:24 PM I am not sure I understand TierNolan's proposition. If transaction is 500 bytes big, why does it need extra 500 bytes space? You are saving it for later blocks. A block full of channel open transactions would be limited to 0.5MB, since each transaction counts as twice as much space. This means that the close transaction costs zero space. If there was an emergency (lots of channels need to be closed quickly due to an DOS attack) miners could produce 10MB blocks which contains 9MB of channel close transactions. This limits the average block size to 1MB (or whatever the limit ends up being) but allows "bursts" above that. Title: Re: Proposals for fast dynamic blocksize Post by: TransaDox on December 15, 2016, 10:13:30 PM I propose a minimum block size of 1MB with an unbounded maximum.
Title: Re: Proposals for fast dynamic blocksize Post by: razoor on December 23, 2016, 11:21:47 AM I propose a minimum block size of 1MB with an unbounded maximum. Can you elaborate how would that work? How do you prevent abusing the system? In my opinion the best way is to do it in similar way as the hash difficulty. Just adjust the block size according to number/size of transactions. If it exceeds 70% of the block size in last X blocks, increase the size. If it's smaller than 40%, make it smaller. Numbers can be of course different but the basic logic works the same with difficulty. Title: Re: Proposals for fast dynamic blocksize Post by: manselr on January 03, 2017, 02:30:32 PM I was thinking about if the monero approach (that is, dynamic blocksize with dynamic fee to avoid spamming trolls) would work with bitcoin? It makes sense to me... im sure it has some sort of tradeoff tho compared to the simple conservative approach we have now but I would like to know, specially what is gmaxwell's opinion on XMR's approach compared to Bitcoin. I think he was XMR friendly and was even holding some. I would like to invest a bit on it, but im not sure it will ever scale. Can they have a LN-like solution too on top the dynamic blocksize+dynamic fee core?
|