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 wrote:
> I guess the most basic question is how do you define a coin here?
On Wed, Dec 9, 2015 at 9:58 PM, Akiva Lichtner wrote:
> 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
Mining equipment is
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
wrote:
> If we partition the work u
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 sto
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 pr
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 bit
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" 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 t
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 a
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
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
be
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, b
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
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 exper
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 co
On Tue, Dec 8, 2015 at 10:27 AM, Akiva Lichtner via bitcoin-dev
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.co
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 adm
16 matches
Mail list logo
