diff options
| author | Joel Joonatan Kaartinen <joel.kaartinen@gmail.com> | 2015-05-09 01:36:56 +0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-05-08 22:37:04 +0000 |
| commit | a654c6391cce447c5fa6a0bfdd3f07976b41c584 (patch) | |
| tree | 59f458ea49482c889f8ec416132ff004a696cf93 | |
| parent | 38a96b125dff4d6995c62f806004747303929f48 (diff) | |
| download | pi-bitcoindev-a654c6391cce447c5fa6a0bfdd3f07976b41c584.tar.gz pi-bitcoindev-a654c6391cce447c5fa6a0bfdd3f07976b41c584.zip | |
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
| -rw-r--r-- | 55/a0c3d05746bc12e365c2885862a0a6721178f8 | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/55/a0c3d05746bc12e365c2885862a0a6721178f8 b/55/a0c3d05746bc12e365c2885862a0a6721178f8 new file mode 100644 index 000000000..798a8db77 --- /dev/null +++ b/55/a0c3d05746bc12e365c2885862a0a6721178f8 @@ -0,0 +1,180 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <joel.kaartinen@gmail.com>) id 1YqqtE-0007OG-7R + for bitcoin-development@lists.sourceforge.net; + Fri, 08 May 2015 22:37:04 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.214.179 as permitted sender) + client-ip=209.85.214.179; envelope-from=joel.kaartinen@gmail.com; + helo=mail-ob0-f179.google.com; +Received: from mail-ob0-f179.google.com ([209.85.214.179]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YqqtC-0008Lm-8z + for bitcoin-development@lists.sourceforge.net; + Fri, 08 May 2015 22:37:04 +0000 +Received: by obcus9 with SMTP id us9so36082638obc.2 + for <bitcoin-development@lists.sourceforge.net>; + Fri, 08 May 2015 15:36:56 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.182.81.137 with SMTP id a9mr195468oby.9.1431124616799; Fri, + 08 May 2015 15:36:56 -0700 (PDT) +Received: by 10.202.49.16 with HTTP; Fri, 8 May 2015 15:36:56 -0700 (PDT) +In-Reply-To: <20150508165144.GC27417@savin.petertodd.org> +References: <16096345.A1MpJQQkRW@crushinator> + <CAP63atbdFSw0rDeuwgtjsDYsXnKSHNN9=zedzip2MsZ0hSY59w@mail.gmail.com> + <CAGKSKfW7fJB6n3B-OoyXOep7hAQqWGGDTiZCkpJ7vXxWRFgveA@mail.gmail.com> + <20150508165144.GC27417@savin.petertodd.org> +Date: Sat, 9 May 2015 01:36:56 +0300 +Message-ID: <CAGKSKfVf6h6icETjfg1joWneiTYob0CTxLDQK-7Pob3+dh_nKQ@mail.gmail.com> +From: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com> +To: Peter Todd <pete@petertodd.org> +Content-Type: multipart/alternative; boundary=047d7b2e3e5869ecc6051599aa51 +X-Spam-Score: -0.6 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (joel.kaartinen[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1YqqtC-0008Lm-8z +Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step + function +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Fri, 08 May 2015 22:37:04 -0000 + +--047d7b2e3e5869ecc6051599aa51 +Content-Type: text/plain; charset=UTF-8 + +such a contract is a possibility, but why would big owners give an +exclusive right to such pools? It seems to me it'd make sense to offer +those for any miner as long as the get paid a little for it. Especially +when it's as simple as offering an incomplete transaction with the +appropriate SIGHASH flags. + +a part of the reason I like this idea is because it will allow stakeholders +a degree of influence on how large the fees are. At least from the surface, +it looks like incentives are pretty well matched. They have an incentive to +not let the fees drop too low so the network continues to be usable and +they also have an incentive to not raise them too high because it'll push +users into using other systems. Also, there'll be competition between +stakeholders, which should keep the fees reasonable. + +I think this would at least be preferable to the "let the miner decide" +model. + +- Joel + +On Fri, May 8, 2015 at 7:51 PM, Peter Todd <pete@petertodd.org> wrote: + +> On Fri, May 08, 2015 at 03:32:00PM +0300, Joel Joonatan Kaartinen wrote: +> > Matt, +> > +> > It seems you missed my suggestion about basing the maximum block size on +> > the bitcoin days destroyed in transactions that are included in the +> block. +> > I think it has potential for both scaling as well as keeping up a +> constant +> > fee pressure. If tuned properly, it should both stop spamming and +> increase +> > block size maximum when there are a lot of real transactions waiting for +> > inclusion. +> +> The problem with gating block creation on Bitcoin days destroyed is +> there's a strong potential of giving big mining pools an huge advantage, +> because they can contract with large Bitcoin owners and buy dummy +> transactions with large numbers of Bitcoin days destroyed on demand +> whenever they need more days-destroyed to create larger blocks. +> Similarly, with appropriate SIGHASH flags such contracting can be done +> by modifying *existing* transactions on demand. +> +> Ultimately bitcoin days destroyed just becomes a very complex version of +> transaction fees, and it's already well known that gating blocksize on +> total transaction fees doesn't work. +> +> -- +> 'peter'[:-1]@petertodd.org +> 00000000000000000f53e2d214685abf15b6d62d32453a03b0d472e374e10e94 +> + +--047d7b2e3e5869ecc6051599aa51 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">such a contract is a possibility, but why would big owners= + give an exclusive right to such pools? It seems to me it'd make sense = +to offer those for any miner as long as the get paid a little for it. Espec= +ially when it's as simple as offering an incomplete transaction with th= +e appropriate SIGHASH flags.<div><br></div><div>a part of the reason I like= + this idea is because it will allow stakeholders a degree of influence on h= +ow large the fees are. At least from the surface, it looks like incentives = +are pretty well matched. They have an incentive to not let the fees drop to= +o low so the network continues to be usable and they also have an incentive= + to not raise them too high because it'll push users into using other s= +ystems. Also, there'll be competition between stakeholders, which shoul= +d keep the fees reasonable.</div><div><br></div><div>I think this would at = +least be preferable to the "let the miner decide" model.</div><di= +v><br></div><div><div>- Joel<br></div><div><div><div><div class=3D"gmail_ex= +tra"><br><div class=3D"gmail_quote">On Fri, May 8, 2015 at 7:51 PM, Peter T= +odd <span dir=3D"ltr"><<a href=3D"mailto:pete@petertodd.org" target=3D"_= +blank">pete@petertodd.org</a>></span> wrote:<br><blockquote class=3D"gma= +il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= +t:1ex"><span class=3D"">On Fri, May 08, 2015 at 03:32:00PM +0300, Joel Joon= +atan Kaartinen wrote:<br> +> Matt,<br> +><br> +> It seems you missed my suggestion about basing the maximum block size = +on<br> +> the bitcoin days destroyed in transactions that are included in the bl= +ock.<br> +> I think it has potential for both scaling as well as keeping up a cons= +tant<br> +> fee pressure. If tuned properly, it should both stop spamming and incr= +ease<br> +> block size maximum when there are a lot of real transactions waiting f= +or<br> +> inclusion.<br> +<br> +</span>The problem with gating block creation on Bitcoin days destroyed is<= +br> +there's a strong potential of giving big mining pools an huge advantage= +,<br> +because they can contract with large Bitcoin owners and buy dummy<br> +transactions with large numbers of Bitcoin days destroyed on demand<br> +whenever they need more days-destroyed to create larger blocks.<br> +Similarly, with appropriate SIGHASH flags such contracting can be done<br> +by modifying *existing* transactions on demand.<br> +<br> +Ultimately bitcoin days destroyed just becomes a very complex version of<br= +> +transaction fees, and it's already well known that gating blocksize on<= +br> +total transaction fees doesn't work.<br> +<span class=3D"HOEnZb"><font color=3D"#888888"><br> +--<br> +'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet= +ertodd.org</a><br> +00000000000000000f53e2d214685abf15b6d62d32453a03b0d472e374e10e94<br> +</font></span></blockquote></div><br></div></div></div></div></div></div> + +--047d7b2e3e5869ecc6051599aa51-- + + |