š
Original date posted:2015-07-28
š Original message:In the interest of promoting some constructive discussion on this, let me start by making a few proposals to correct the listed issues.
Note: many of these ideas are neither my own nor really all that new, but it seems in the past weāve given up too easily on actually moving forward on them despite their critical importance.
āā
1) A fee market never really got created, we donāt really know how transaction fees would work in practice.
The only way to see how fees would work in practice is to have scarcity. If the network is still not sufficiently mature to be able to handle actual resource limits securely, the safest way to do this is to artificially impose limits. Some economists might bicker about the problems with production quotas and what notā¦but how else are we to solve the real, non-trivial engineering problems without risking system collapse? The eventual goal would be to remove these artificial limits once weāre confident that the economic incentives are properly aligned to maintain security. Weāre still quite far from this goal, though, and it would be irresponsible, IMHO, to insist on letting the system hit its real limits.
2) Turns out the vast majority of validation nodes have little if anything to do with mining - validators do not get compensatedā¦validation cost is externalized to the entire network.
3) Miners donāt even properly validate blocks. And the bigger the blocks get, the greater the propensity to skip this step. Oops!
Issues (2) and (3) are inextricably related so Iāll cover both together.
The obvious problem here is that as long as the cost of checking validators is the same as the cost of validating itself, thereās really little we can do to properly have any sort of division of labor. Requiring, at the very least, random checks might be a start. Perhaps some clever use of SNARKs might eventually be secure and practical.
It might also be possible to directly pay validators for satisfying random checks or providing SNARKs. If only we could trustlessly and securely outsource this work weād make tremendous progress.
Of all the issues Iāve listed, these are perhaps the ones for which practical solutions seem most tentative at present.
4) A satisfactory mechanism for thin clients to be able to securely obtain reasonably secure, short proofs for their transactions never materialized.
The first part of the solution to this issue is the use of better data structures. Satoshiās SPV can prove that transactions are included in blocksā¦and that outputs are spent. But it has no mechanism for proving that a given transaction is *not* included in any blockā¦or that some particular output remains unspent. The structures to which weāre committing extremely inefficient for querying some of the most important things required for validationā¦i.e. whether an output exists and whether it is spent.
The second part is shifting the responsibility for constructing proofs to the parties who already have the greatest incentives to store the necessary data to construct these proofs to allow efficient prunability. Outsourceability of proofs would also be highly desirable.
āā
If we want to be able to raise the block size limitā¦or perhaps get rid of it altogether, I would suggest we start by addressing these specific issues and work to find practical solutions. Since raising the block size limit is already a hard forking consensus rule change, at least the need for hard forks isnāt whatās stopping us.
- Eric
> On Jul 28, 2015, at 5:55 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> I agree that the historical reasons are irrelevant from an engineering perspective. But they still set a context for the discussionā¦and might help shed some insight into the motivations behind some of the participants. Itās also good to know these things to counter arguments that start with āBut Satoshi said thatā¦ā
>
> Whatās critically important to note is that several of the assumptions that were being made at the time this limit was decided have turned out wrongā¦and that these other issues should probably be of greater concern and more highly prioritized in any discussion considering the merits of deploying potentially incompatible consensus rule changes. It seems if these other issues were fixed perhaps no block size limit would be required at all (as was originally hoped).
>
> - Eric
>
>> On Jul 28, 2015, at 5:46 PM, Mark Friedenbach <mark at friedenbach.org <mailto:mark at friedenbach.org>> wrote:
>>
>> Does it matter even in the slightest why the block size limit was put in place? It does not. Bitcoin is a decentralized payment network, and the relationship between utility (block size) and decentralization is empirical. Why the 1MB limit was put in place at the time might be a historically interesting question, but it bears little relevance to the present engineering issues.
>>
>> On Tue, Jul 28, 2015 at 5:43 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> > Enter a ātemporaryā anti-spam measure - a one megabyte block size limit. Letās test this out, then increase it once we see how things work. So far so goodā¦
>> >
>>
>> The block size limit was put in place as an anti-DoS measure (monster blocks), not "anti-spam". It was never intended to have any economic effect, not on spam and not on any future fee market.
>>
>>
>> jp
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150728/f797244b/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150728/f797244b/attachment-0001.sig>;
