Akiva Lichtner [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-12-08 to 2016-06-21
💬 Posted a total of 8 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:51:30

- reply

📅 Original date posted:2016-06-21
📝 Original message:I am a long-time developer and I have some experience in process groups. I
am going to try to keep this short. If you are interested in pursuing this
idea please reply to me privately so we don't put a burden on the list.
As per Satoshi's paper, the blockchain implements a distributed timestamp
service. It defeats double-spending by establishing a "total order" on
transactions. The "domain" on which the ordering takes place is the entire
coin, the money supply. It's obvious to me that total ordering does not
scale well as a use case, it's not a matter of implementation details or
design. It's the requirement which is a problem. Therefore when I see
mention of the many clever schemes proposed to make Bitcoin scalable I
already know that by using that proposal we are going to give up something.
And in some cases I see lengthy and complex proposals, and just what the
user is giving up is not easy to see.
I think that the user has to give up something in order for electronic cash
to really scale, and that something has to be non-locality. At the moment
Bitcoin doesn't know whether I am buying a laptop from 3,000 miles away or
300. This is a wonderful property, but this property makes it impossible to
partition the users geographically. I think that a simple and effective way
to do this is to partition the address using a hash. A convention could be
adopted whereby there is a well-known partition number for each geographic
location. Most users would use third-party clients and the client could
generate Bitcoin addresses until it hits one in the user's geographical
area.
The partitioning scheme could be hierarchical. For example there could be
partitions at the city, state, and country level. A good way to see how
this works in real life is shopping at Walmart, which is something like
4,000 stores. Walmart could have users pay local addresses, and then move
the money "up" to a regional or country level.
The problem is what to do when an address in partition A wants to pay an
address in partition B. This should be done by processing the transaction
in partition A first, and once the block is made a hash of that block
should be included in some block in partition B. After A has made the block
the coin has left A, it cannot be spent. Once B has made its block the coin
has "arrived" in B and can be spent. It can be seen that some transactions
span a longer distance than others, in that they require two or more
blocks. These transactions take longer to execute, and I think that that is
entirely okay.
Transaction verification benefits because a small merchant can accept
payments from local addresses only. Larger merchants can verify
transactions across two or more partitions.
Some will be concerned about 51% attacks on partitions. I would point
out that nodes could process transactions at random, so that the majority
of the computing power is well-balanced across all partitions.
Regards,
Akiva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/a5aebe68/attachment.html>

2023-06-07 17:45:59

- reply

📅 Original date posted:2015-12-10
📝 Original message:Hi Andrew,
What you suggested is much more sophisticated than what I suggested. I am
strictly talking about independent chains - that's all.
I am struck by the fact that the topic of "scaling bitcoin" seems to be a
mix of different problems, and when people are really trying to solve
different problems, or arguing about applying the same solution in
different settings, it's easy to argue back and forth endlessly. Your post
talks about validating transactions without seeing all transactions. This
is a different problem than what I am addressing. My view of Bitcoin is
colored by my experience with process groups and total ordering. I view
Bitcoin as a timestamp service on all transactions, a total order. A total
order is difficult to scale. Period.
I am just addressing how to change the system so that blocks can be
generated faster if a) the transaction volume increases and b) you are
willing to have more miners. But you are also talking about transaction
verification and making sure that you don't need to verify everything. I
think these are two problems that should have two different names.
Correct me if I am wrong, but the dream of a virtual currency where
everybody is equal and runs the client on their mobile device went out the
window long ago. I think that went out with the special mining hardware. If
my organization had to accept bitcoin payments I would assume that we'll
need a small server farm for transaction verification, and that we would
see all the transactions. Figure 10,000 transactions per second, like VISA.
As far as small organizations or private individuals are concerned, I think
it would be entirely okay for a guy on a smartphone to delegate
verification to a trusted party, as long as the trust chain stops there and
there is plenty of choice.
I am guessing the trustless virtual currency police would get pretty upset
about such a pragmatic approach, but it's not really a choice, the failure
to scale has already occurred. All things considered I think that Bitcoin
will only scale when pragmatic considerations take center stage and the
academic goals take a lower priority. I would think companies would make a
good living out of running trusted verification services.
Once again, it doesn't mean that there is a bank, the network still allows
malicious nodes, but there can be pockets of trust. This is only natural,
most people trust at least one other person, so it's not that weird.
Akiva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/0844f5e2/attachment-0001.html>

2023-06-07 17:45:58

- reply

📅 Original date posted:2015-12-10
📝 Original message:It's an interval (a,b) where a, b are between 0 and 21*10^6*10^8 .
Somebody pointed out that this is not easily accomplished using the current
code because there are no coin ids.
On Wed, Dec 9, 2015 at 4:16 PM, Loi Luu <loi.luuthe at gmail.com> wrote:
> I guess the most basic question is how do you define a coin here?
>
> Thanks,
> Loi Luu
> On 10 Dec 2015 2:26 a.m., "Akiva Lichtner" <akiva.lichtner at gmail.com>
> wrote:
>
>> Thanks for giving serious consideration to my post.
>>
>> With regard to your question "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?", I would answer that only one
>> partition is involved. In other words, there are N independent block
>> chains that never cross paths.
>>
>> With regard to your question "what is the prior data needed to
>> validate that kind of TXs?" I do not understand what this means. If
>> you can dumb it down a bit that would be good because there could be
>> some interesting concern in this question.
>>
>> Since partitions are completely segregated, there is no need for a
>> node to work on multiple partitions simultaneously. For attacks to be
>> defeated a node needs to be able to work on multiple partitions in
>> turn, not at the same time. The reason is because if the computing
>> power of the good-faith nodes is unbalanced this gives attackers an
>> unfair advantage.
>>
>> On 12/9/15, Loi Luu via bitcoin-dev
>> <bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >>
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/8f725842/attachment.html>

2023-06-07 17:45:57

- reply

📅 Original date posted:2015-12-09
📝 Original message:Thanks for giving serious consideration to my post.
With regard to your question "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?", I would answer that only one
partition is involved. In other words, there are N independent block
chains that never cross paths.
With regard to your question "what is the prior data needed to
validate that kind of TXs?" I do not understand what this means. If
you can dumb it down a bit that would be good because there could be
some interesting concern in this question.
Since partitions are completely segregated, there is no need for a
node to work on multiple partitions simultaneously. For attacks to be
defeated a node needs to be able to work on multiple partitions in
turn, not at the same time. The reason is because if the computing
power of the good-faith nodes is unbalanced this gives attackers an
unfair advantage.
On 12/9/15, Loi Luu via bitcoin-dev
<bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

2023-06-07 17:45:56

- reply

📅 Original date posted:2015-12-08
📝 Original message:If the system is modified to scale up that means the number of transactions
is going up. That means the number of miners can also go up, and so will
the portion of malicious nodes. At least this seems reasonable. The problem
with partitions is that an attacker can focus on one partition. However
because the number of miners also increases any attacks will fail as long
as the miners are willing to work on any partition, which is easily
accomplished by round-robin.
Since there are N times more miners each miner still does the same amount
of work. The system scales by partitioning the money supply and increasing
the number of miners.
On Tue, Dec 8, 2015 at 4:29 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If partition is selected from a random key (the hash of the output for
> example) then payment recipients would need to operate a full node on each
> of the chains.
>
> What's the point of partitioning if virtually everybody needs to operate
> each partition?
>
> The mining aspect has it's own set of issues, but I'm not going to get
> into those.
>
> On 12/08/2015 01:23 PM, Akiva Lichtner wrote:
>
> 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.
>
> 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.
>
> On Tue, Dec 8, 2015 at 3:50 PM, Patrick Strateman via bitcoin-dev <
> <bitcoin-dev at lists.linuxfoundation.org>
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Payment recipients would need to operate a daemon for each chain, thus
>> guaranteeing no scaling advantage.
>>
>> (There are other issues, but I believe that to be enough of a show
>> stopper not to continue).
>>
>> On 12/08/2015 08:27 AM, Akiva Lichtner via bitcoin-dev 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 listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/bbd37f43/attachment-0001.html>

2023-06-07 17:45:55

- reply

📅 Original date posted:2015-12-08
📝 Original message:Thanks for your response and links.
I think the difference is that those proposals all shard the mining work,
whereas what I wrote in my post shards the coin itself. In other words
different parts of the coin space are forever segregated, never ending up
in the same block. It's a big difference conceptually because I could spend
money and a fraction of it makes it into a block in ten minutes and the
rest two hours later.
And I think that's where the potential for the scalability comes in. I am
not really scaling Bitcoin's present requirements, I am relaxing the
requirements in a way that leaves the users and the miners happy, but that
could provoke resistance by the part of of all of us that doesn't want
digital cash as much as it wants to make history.
All the best,
Akiva
P.S. Thanks for pointing out that I hit "reply" instead of "reply all"
earlier ...
On Tue, Dec 8, 2015 at 11:45 AM, Bryan Bishop <kanzure at gmail.com> wrote:
> On Tue, Dec 8, 2015 at 10:27 AM, Akiva Lichtner via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > and miners would have to round-robin through partitions
>
> At first glance this proposal seems most similar to the sharding proposals:
>
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/
> https://github.com/vbuterin/scalability_paper/blob/master/scalability.pdf
>
> https://www.reddit.com/r/Bitcoin/comments/3u1m36/why_arent_we_as_a_community_talking_about/cxbamhn
> http://eprint.iacr.org/2015/1168.pdf (committee approach)
>
> > but clients would have to send more than one message in order to spend
> money
>
> Offloading work to the client for spends has in the past been a
> well-received concept, such as the linearized coin history idea.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/fb4dadb7/attachment.html>

2023-06-07 17:45:55

- reply

📅 Original date posted:2015-12-08
📝 Original message: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.
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.
On Tue, Dec 8, 2015 at 3:50 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Payment recipients would need to operate a daemon for each chain, thus
> guaranteeing no scaling advantage.
>
> (There are other issues, but I believe that to be enough of a show stopper
> not to continue).
>
> On 12/08/2015 08:27 AM, Akiva Lichtner via bitcoin-dev 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 listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/9de15dd2/attachment.html>

2023-06-07 17:45:54

- reply

📅 Original date posted:2015-12-08
📝 Original message: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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/37780f8d/attachment.html>