<div dir="ltr"><div>It's true that miners would have to be prepared to work on any partition. I don't see where the number affects defeating double spending, what matters is the nonce in the block that keeps the next successful miner random.<br><br></div>I expect that the number of miners would be ten times larger as well, so an attacker would have no advantage working on one partition.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 3:50 PM, Patrick Strateman via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Payment recipients would need to operate a daemon for each chain,
thus guaranteeing no scaling advantage.<br>
<br>
(There are other issues, but I believe that to be enough of a show
stopper not to continue).<br>
<br>
<div>On 12/08/2015 08:27 AM, Akiva Lichtner
via bitcoin-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Hello,<br>
<br>
</div>
I am seeking some expert feedback on an idea for
scaling Bitcoin. As a brief introduction: I work
in the payment industry and I have twenty years'
experience in development. I have some experience
with process groups and ordering protocols too. I
think I understand Satoshi's paper but I admit I
have not read the source code.<br>
<br>
</div>
The idea is to run more than one simultaneous chain,
each chain defeating double spending on only part of
the coin. The coin would be partitioned by radix (or
modulus, not sure what to call it.) For example in
order to multiply throughput by a factor of ten you
could run ten parallel chains, one would work on
coin that ends in "0", one on coin that ends in "1",
and so on up to "9".<br>
<br>
</div>
The number of chains could increase automatically over
time based on the moving average of transaction
volume.<br>
<br>
</div>
Blocks would have to contain the number of the partition
they belong to, and miners would have to round-robin
through partitions so that an attacker would not have an
unfair advantage working on just one partition.<br>
</div>
<div><br>
</div>
<div>I don't think there is much impact to miners, but
clients would have to send more than one message in
order to spend money. Client messages will need to
enumerate coin using some sort of compression, to save
space. This seems okay to me since often in computing
client software does have to break things up in equal
parts (e.g. memory pages, file system blocks,) and the
client software could hide the details.<br>
</div>
</div>
<div><br>
</div>
<div>Best wishes for continued success to the project.<br>
</div>
<div><br>
</div>
Regards,<br>
</div>
Akiva<br>
<br>
</div>
P.S. I found a funny anagram for SATOSHI NAKAMOTO: "NSA IS OOOK
AT MATH"<br>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
bitcoin-dev mailing list
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>