path: root/73/9940b54668ca12bd93e03e353d4efd03cf6bf6

Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 37BF7EEA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 10 Dec 2015 04:14:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com
	[209.85.218.52])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A9861135
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 10 Dec 2015 04:14:18 +0000 (UTC)
Received: by oies6 with SMTP id s6so38887687oie.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 09 Dec 2015 20:14:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=9jxT0aydGQPl2eWNf/bg1wFqwzYKJa8kZnr8VbHhy2E=;
	b=JkNn7WhZe3HyUUL1IdxNiHtFMARWjC3y9Fvh9xgCHaLeESy8FHbFEczroPR0dZ5GbP
	408X5TNspCIHIFa0LsgIofFmblMdvk+gfzYYt0cNWMWZwJH5/klsgLGkNjOBH1fUZR0f
	WI9oW68QnpHkmSjjIanemDPnGzvgnpQ8Bwm90w9kNO7lBC1+LTqYJtRC8/saUQ4mMfzw
	/Lzlk6i92wgqD68h7Ajb8VZoXJTwZ+RoATfwX0JgXj3RHu/z6tE0P8v2/uO1hPO4jSie
	mblZxR6tDSf94uiZSIr0xByCj7RwLhbBorMDe0ODy9eNLxX/cASRadPSNT1hqUVCdJ1W
	Se8w==
MIME-Version: 1.0
X-Received: by 10.202.222.193 with SMTP id v184mr7316305oig.15.1449720858046; 
	Wed, 09 Dec 2015 20:14:18 -0800 (PST)
Sender: dscotese@gmail.com
Received: by 10.60.15.169 with HTTP; Wed, 9 Dec 2015 20:14:17 -0800 (PST)
In-Reply-To: <CAGLBAhebzN9FZ0TQO+Xr1SmKH5YFptbQ=M09+c511siAq9dmNQ@mail.gmail.com>
References: <CABCnA7Wqz76m8qo5BYT41Z=hBH+fUfOc4xsFAGg=Niv7Jgkqsg@mail.gmail.com>
	<CAJmQggC1X5Lgt4xGoMtBZ_v3hC2GXcYaj2FngV2_7A=TDfSuEg@mail.gmail.com>
	<CAL8tG=mxYE97iMO05mPq4_f8VcmFBYqAmyPqTs439bPRGhaVqA@mail.gmail.com>
	<CAGLBAhebzN9FZ0TQO+Xr1SmKH5YFptbQ=M09+c511siAq9dmNQ@mail.gmail.com>
Date: Wed, 9 Dec 2015 20:14:17 -0800
X-Google-Sender-Auth: -BWqCU1H-A6FfLKyopeG3odwZSQ
Message-ID: <CAGLBAhcWfjkhbxU-qxxEbBbpZ9jrbgLUVODth+jYT6t+Ocgyrg@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Andrew <onelineproof@gmail.com>
Content-Type: multipart/alternative; boundary=001a113d54d4c4799d05268370c8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling by Partitioning
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2015 04:14:20 -0000

--001a113d54d4c4799d05268370c8
Content-Type: text/plain; charset=UTF-8

Edit:
"... as well as those blocks with hashes for which the last B bits match
any of the next N bit patterns where *N is largest* integer for which the
claimed output is not *greater* than (subsidy+fees)*(N/(2^B)).

On Wed, Dec 9, 2015 at 8:08 PM, Dave Scotese <dscotese@litmocracy.com>
wrote:

> If we partition the work using bits from the TxID (once it is no longer
> malleable) or even bits from whatever definition we use for "coin," then
> every transaction may have to use all the other partitions to verify that
> the incoming coin is good.
>
> If all partitions are involved in validating and storing every
> transaction, then we may be doing more work in total, but any one node will
> only have to do (and store) a fraction of what it is now.  We would want
> the current situation to be identical to one in which all the participants
> are handling all the partitions.  So how can we break up the work so that
> any participant can handle whatever fraction of the work he or she wants?
> One idea is to use the last bits of the address that will receive the
> subsidy and fees.  You solve the block for your partition by determining
> that all transactions in the block are valid against the subset of blocks
> whose hashes end with the same bits.
>
> This solution is broadcast in the hope that others will start attempting
> to validate that same block on their own partition. If they are mining the
> same partition, they simply change their subsidy address to work on a
> different partition.  Each time a new-but-not-last partition is solved,
> everyone working on the block adds the new solver's output address to their
> generation transaction with the appropriate fraction of the
> reward-plus-subsidy.  In this way, several miners contribute to the
> solution of a single block and need only store those blocks that match the
> partitions they want to work on.
>
> Suppose we use eight bits so that there are 256 partitions and a miner
> wishes to do about 1/5 of the work. That would be 51 partitions.  This is
> signaled in the generation transaction, where the bit-pattern of the last
> byte of the public key identifies the first partition, and the proportion
> of the total reward for the block (51/256) indicates how many partitions a
> solution will cover.
>
> Suppose that the last byte of the subsidy address is 0xF0.  This means
> there are only 16 partitions left, so we define partition selection to wrap
> around.  This 51/256 miner must cover partitions 0xF0 - 0xFF and 0x00 -
> 0x23. In this way, all mining to date has covered all partitions.
>
> The number of bits to be used might be able to be abstracted out to a
> certain level.  Perhaps a miner can indicate how many bits B the
> partitioning should use in the CoinBase. The blocks for which a partition
> miner claims responsibility are all those with a bit pattern of length B at
> the end of their hash matching the the bits at the end of the first
> output's public key in the generation transaction, as well as those blocks
> with hashes for which the last B bits match any of the next N bit patterns
> where for the largest integer N for which the claimed output is not less
> than (subsidy+fees)*(N/(2^B)).
>
> If you only store and validate against one partition, and that partition
> has a solution already, then you would start working on the next block
> (once you've validated the current one against your subset of the
> blockchain).  You could even broadcast a solution for that next block
> before the previous block is fully solved, thus claiming a piece of the
> next block reward (assuming the current block is valid on all partitions).
>
> It seems that a miner who covers only one partition will be at a serious
> disadvantage, but as the rate of incoming transactions increases, the
> fraction of time he must spend validating (being about half of all other
> miners who cover just one more partition) makes up for this disadvantage
> somewhat.  He is a "spry" miner and therefore wins more rewards during
> times of very dense transaction volume.  If we wish to encourage miners to
> work on smaller partitions, we can provide a difficulty break for smaller
> fractions of the work.  In fact, the difficulty can be adjusted down for
> the first solution, and then slowly back up to full for the last
> partition(s).
>
> This proposal has the added benefit of encouraging the assembly of blocks
> by miners who work on single partitions to get them out there with a
> one-partition solution.
>
> On Wed, Dec 9, 2015 at 2:35 PM, Andrew via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Akiva
>>
>> I sketched out a similar proposal here:
>> https://bitcointalk.org/index.php?topic=1083345.0
>>
>> It's good to see people talking about this :). I'm not quite convinced
>> with segregated witness, as it might mess up some things, but will take a
>> closer look.
>> On Dec 9, 2015 7:32 AM, "Loi Luu via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Dear Akiva,
>>>
>>> Its Loi Luu, one of the authors of the SCP protocol (
>>> http://eprint.iacr.org/2015/1168.pdf ).
>>>
>>> Before SCP, we had been thinking hard about how to do sharding
>>> efficiently without degrading any security guarantee. A simple solution
>>> which splits the coins, or TXs in to several partitions will just not work.
>>> You have to answer more questions to have a good solutions. For example, I
>>> wonder in your proposal, if a transaction spends a "coin" that ends in "1"
>>> and creates a new coin that ends in "1", which partition should process the
>>> transaction? What is the prior data needed to validate that kind of TXs?
>>>
>>> The problem with other proposals, and probably yours as well,  that we
>>> see is that the amount of data that you need to broadcast immediately to
>>> the network increases linearly with the number of TXs that the network can
>>> process. Thus, sharding does not bring any advantage than simply using
>>> other techniques to publish more blocks in one epoch (like Bitcoin-NG,
>>> Ghost). The whole point of using sharding/ partition is to localize
>>> the bandwidth used, and only broadcast only a minimal data to the network.
>>>
>>> Clearly we are able to localize the bandwidth used with our SCP
>>> protocol. The cost is that now recipients need to  themselves verify
>>> whether a transaction is double spending. However, we think that it is a
>>> reasonable tradeoff, given the potential scalability that SCP can provides.
>>>
>>> Thanks,
>>> Loi Luu.
>>>
>>> On Wed, Dec 9, 2015 at 12:27 AM, Akiva Lichtner via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Hello,
>>>>
>>>> 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.
>>>>
>>>> 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".
>>>>
>>>> The number of chains could increase automatically over time based on
>>>> the moving average of transaction volume.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> Best wishes for continued success to the project.
>>>>
>>>> Regards,
>>>> Akiva
>>>>
>>>> P.S. I found a funny anagram for SATOSHI NAKAMOTO: "NSA IS OOOK AT MATH"
>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>



-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

--001a113d54d4c4799d05268370c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Edit:<br>&quot;... as well as those blocks with hashes for=
 which the last B bits match any
 of the next N bit patterns where <b>N is largest</b> integer for which=20
the claimed output is not <b>greater</b> than (subsidy+fees)*(N/(2^B)).</di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Dec 9, =
2015 at 8:08 PM, Dave Scotese <span dir=3D"ltr">&lt;<a href=3D"mailto:dscot=
ese@litmocracy.com" target=3D"_blank">dscotese@litmocracy.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>=
<div><div>If we partition the work using bits from the TxID (once it is no =
longer malleable) or even bits from whatever definition we use for &quot;co=
in,&quot; then every transaction may have to use all the other partitions t=
o verify that the incoming coin is good.<br><br></div>If all partitions are=
 involved in validating and storing every transaction, then we may be doing=
 more work in total, but any one node will only have to do (and store) a fr=
action of what it is now.=C2=A0 We would want the current situation to be i=
dentical to one in which all the participants are handling all the partitio=
ns.=C2=A0 So how can we break up the work so that any participant can handl=
e whatever fraction of the work he or she wants?=C2=A0 One idea is to use t=
he last bits of the address that will receive the subsidy and fees.=C2=A0 Y=
ou solve the block for your partition by determining that all transactions =
in the block are valid against the subset of blocks whose hashes end with t=
he same bits.<br><br></div>This solution is broadcast in the hope that othe=
rs will start attempting to validate that same block on their own partition=
. If they are mining the same partition, they simply change their subsidy a=
ddress to work on a different partition.=C2=A0 Each time a new-but-not-last=
 partition is solved, everyone working on the block adds the new solver&#39=
;s output address to their generation transaction with the appropriate frac=
tion of the reward-plus-subsidy.=C2=A0 In this way, several miners contribu=
te to the solution of a single block and need only store those blocks that =
match the partitions they want to work on.<br><br></div>Suppose we use eigh=
t bits so that there are 256 partitions and a miner wishes to do about 1/5 =
of the work. That would be 51 partitions.=C2=A0 This is signaled in the gen=
eration transaction, where the bit-pattern of the last byte of the public k=
ey identifies the first partition, and the proportion of the total reward f=
or the block (51/256) indicates how many partitions a solution will cover.<=
br><br>Suppose that the last byte of the subsidy address is 0xF0.=C2=A0 Thi=
s means there are only 16 partitions left, so we define partition selection=
 to wrap around.=C2=A0 This 51/256 miner must cover partitions 0xF0 - 0xFF =
and 0x00 - 0x23. In this way, all mining to date has covered all partitions=
.<br><br></div><div>The number of bits to be used might be able to be abstr=
acted out to a certain level.=C2=A0 Perhaps a miner can indicate how many b=
its B the partitioning should use in the CoinBase. The blocks for which a p=
artition miner claims responsibility are all those with a bit pattern of le=
ngth B at the end of their hash matching the the bits at the end of the fir=
st output&#39;s public key in the  generation transaction, as well as those=
 blocks with hashes for which the last B bits match any of the next N bit p=
atterns where for the largest integer N for which the claimed output is not=
 less than (subsidy+fees)*(N/(2^B)).<br></div><div><br></div><div>If you on=
ly store and validate against one partition, and that partition has a solut=
ion already, then you would start working on the next block (once you&#39;v=
e validated the current one against your subset of the blockchain).=C2=A0 Y=
ou could even broadcast a solution for that next block before the previous =
block is fully solved, thus claiming a piece of the next block reward (assu=
ming the current block is valid on all partitions).<br></div><div><br></div=
>It seems that a miner who covers only one partition will be at a serious d=
isadvantage, but as the rate of incoming transactions increases, the fracti=
on of time he must spend validating (being about half of all other miners w=
ho cover just one more partition) makes up for this disadvantage somewhat.=
=C2=A0 He is a &quot;spry&quot; miner and therefore wins more rewards durin=
g times of very dense transaction volume.=C2=A0 If we wish to encourage min=
ers to work on smaller partitions, we can provide a difficulty break for sm=
aller fractions of the work.=C2=A0 In fact, the difficulty can be adjusted =
down for the first solution, and then slowly back up to full for the last p=
artition(s).<br><br></div>This proposal has the added benefit of encouragin=
g the assembly of blocks by miners who work on single partitions to get the=
m out there with a one-partition solution.<br></div><div class=3D"gmail_ext=
ra"><div><div class=3D"h5"><br><div class=3D"gmail_quote">On Wed, Dec 9, 20=
15 at 2:35 PM, Andrew via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><p dir=3D"ltr">Hi Akiva</p>
<p dir=3D"ltr">I sketched out a similar proposal here: <a href=3D"https://b=
itcointalk.org/index.php?topic=3D1083345.0" target=3D"_blank">https://bitco=
intalk.org/index.php?topic=3D1083345.0</a></p>
<p dir=3D"ltr">It&#39;s good to see people talking about this :). I&#39;m n=
ot quite convinced with segregated witness, as it might mess up some things=
, but will take a closer look.</p>
<div class=3D"gmail_quote"><span>On Dec 9, 2015 7:32 AM, &quot;Loi Luu via =
bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<=
br type=3D"attribution"></span><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><span style=3D"font-size:12.8000001907349px">Dear Akiva,</span><div sty=
le=3D"font-size:12.8000001907349px"><br></div><div style=3D"font-size:12.80=
00001907349px">Its Loi Luu, one of the authors of the SCP protocol (<a href=
=3D"http://eprint.iacr.org/2015/1168.pdf" rel=3D"noreferrer" style=3D"font-=
size:12.8000001907349px" target=3D"_blank">http://eprint.iacr.org/2015/1168=
.pdf</a><span style=3D"font-size:12.8000001907349px">=C2=A0).</span></div><=
span><div style=3D"font-size:12.8000001907349px"><span style=3D"font-size:1=
2.8000001907349px"><br></span></div><div style=3D"font-size:12.800000190734=
9px"><span style=3D"font-size:12.8000001907349px">Before SCP, we had been t=
hinking hard about how to do sharding efficiently without degrading any sec=
urity guarantee. A simple solution which splits the coins, or TXs in to sev=
eral partitions will just not work. You have to answer more questions to ha=
ve a good solutions. For example, I wonder in your proposal, if a transacti=
on spends a &quot;coin&quot; that ends in &quot;1&quot; and creates a new c=
oin that ends in &quot;1&quot;, which partition should process the transact=
ion? What is the prior data needed to validate that kind of TXs?</span></di=
v><div style=3D"font-size:12.8000001907349px"><span style=3D"font-size:12.8=
000001907349px"><br></span></div><div style=3D"font-size:12.8000001907349px=
"><span style=3D"font-size:12.8000001907349px">The problem with other propo=
sals, and probably yours as well,=C2=A0=C2=A0that we see is that the amount=
 of data that you need to broadcast immediately to the network increases li=
nearly with the number of TXs that the network can process. Thus, sharding =
does not bring any advantage than simply using other techniques to publish =
more blocks in one epoch (like Bitcoin-NG, Ghost). The whole point of using=
 sharding/ partition is to localize the=C2=A0bandwidth=C2=A0used, and only =
broadcast only a=C2=A0minimal=C2=A0data to the network.</span></div><div st=
yle=3D"font-size:12.8000001907349px"><span style=3D"font-size:12.8000001907=
349px"><br></span></div><div style=3D"font-size:12.8000001907349px"><span s=
tyle=3D"font-size:12.8000001907349px">Clearly we are able to localize the b=
andwidth used with our SCP protocol. The cost is that now=C2=A0recipients=
=C2=A0need to=C2=A0</span><span style=3D"font-size:12.8000001907349px">=C2=
=A0</span><span style=3D"font-size:12.8000001907349px">themselves=C2=A0veri=
fy whether a transaction is double spending. However, we think that=C2=A0it=
 is=C2=A0a reasonable tradeoff, given the potential scalability that SCP ca=
n provides.</span></div><div class=3D"gmail_extra"><br clear=3D"all"><div><=
div><div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif;font-size:=
13px;border-collapse:collapse;color:rgb(136,136,136)"><span style=3D"color:=
rgb(0,0,102)"><div>Thanks,</div><div>Loi Luu.<br></div></span></span></div>=
</div></div>
<br><div class=3D"gmail_quote">On Wed, Dec 9, 2015 at 12:27 AM, Akiva Licht=
ner via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><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 introducti=
on: I work in the payment industry and I have twenty years&#39; experience =
in development. I have some experience with process groups and ordering pro=
tocols too. I think I understand Satoshi&#39;s paper but I admit I have not=
 read the source code.<br><br></div>The idea is to run more than one simult=
aneous 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 co=
uld run ten parallel chains, one would work on coin that ends in &quot;0&qu=
ot;, one on coin that ends in &quot;1&quot;, and so on up to &quot;9&quot;.=
<br><br></div>The number of chains could increase automatically over time b=
ased 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 wou=
ld have to round-robin through partitions so that an attacker would not hav=
e an unfair advantage working on just one partition.<br></div><div><br></di=
v><div>I don&#39;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 t=
o break things up in equal parts (e.g. memory pages, file system blocks,) a=
nd the client software could hide the details.<br></div></div><div><br></di=
v><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: &quot;NSA IS OOOK AT MATH&quot;<br><br></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div></span></div><span>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></span></blockquote></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br><br clear=3D"all"><br></div></div><span class=3D=
"HOEnZb"><font color=3D"#888888">-- <br><div><div dir=3D"ltr">I like to pro=
vide some work at no charge to prove my value. Do you need a techie?=C2=A0 =
<br>I own <a href=3D"http://www.litmocracy.com" target=3D"_blank">Litmocrac=
y</a> and <a href=3D"http://www.memeracing.net" target=3D"_blank">Meme Raci=
ng</a> (in alpha). <br>I&#39;m the webmaster for <a href=3D"http://www.volu=
ntaryist.com" target=3D"_blank">The Voluntaryist</a> which now accepts Bitc=
oin.<br>I also code for <a href=3D"http://dollarvigilante.com/" target=3D"_=
blank">The Dollar Vigilante</a>.<br>&quot;He ought to find it more profitab=
le to play by the rules&quot; - Satoshi Nakamoto</div></div>
</font></span></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature"><div dir=3D"ltr">I like to provide some work at no charge to prove =
my value. Do you need a techie?=C2=A0 <br>I own <a href=3D"http://www.litmo=
cracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"http://www.memer=
acing.net" target=3D"_blank">Meme Racing</a> (in alpha). <br>I&#39;m the we=
bmaster for <a href=3D"http://www.voluntaryist.com" target=3D"_blank">The V=
oluntaryist</a> which now accepts Bitcoin.<br>I also code for <a href=3D"ht=
tp://dollarvigilante.com/" target=3D"_blank">The Dollar Vigilante</a>.<br>&=
quot;He ought to find it more profitable to play by the rules&quot; - Satos=
hi Nakamoto</div></div>
</div>

--001a113d54d4c4799d05268370c8--