Pages:
Author

Topic: BlockReduce: Scaling Blockchain to human commerce (Read 1305 times)

copper member
Activity: 9
Merit: 3


However, I would contend that with larger user base even if the cost of running a fully validating node increases, the absolute number of full nodes would likely go up not down even if the relative number shrinks.


That does not make sense.

I think what he means is that with more people using the network, the number of full nodes that run on the network will go up, but the ratio of full node to user will not increase. But I don't see this as such a big issue if users are allowed to run whichever part of the network that they wish or interact with economically speaking. For example, if I am geographically located in Region 1 Zone 2, I will run a node in Prime, Region 1, and Zone 2 as I do most of my commerce in those networks. Because data from a Zone is compressed when it moves into a Region (and Region data is compressed when it moves into Prime) the resources required for running the three nodes would not be that much higher than running a Bitcoin node. Now if you are a merchant I'm guessing you would want to run nodes in multiple zones (to accept payment in those zones), so the hardware requirement there would be greater, but you have an economic incentive to do so.

I have another question OP. When a transaction moves from zone to zone, there is a 'state transition' that takes place, correct? The transaction would go from zone to region to prime and then to zone (assuming the two zones are not in the same region) so the zone that the transaction enters would need to have some state transition that is not necessarily in a block but is also reversible (I suppose this could show up in a block in the other zone). What happens if the transaction is reversed in Prime due to an orphan or re-org? Does the other zone chain need to re-org its UTXO set?

Looking forward to hearing more, thanks.
legendary
Activity: 2898
Merit: 1823

Then I would debate that the statement, "allowing it to scale to handle tens of thousands of transactions per second without impacting fault tolerance or decentralization", is u true.


The actual effect on fault tolerance and decentralization has to be put into context that currently over 50% of Bitcoin's hashpower comes from only 4 pools.  As BlockReduce scales the node requirements to have a node which does partial state validation would be much less then a if Bitcoin scaled in its current state.  That would mean that although there may be fewer people validating full state, there will be more people, and fewer pools validating partial state. I would argue that having partially validating mining nodes is advantageous over having a deminimis number of pools.  Having smaller economic entities decide on the fate of the protocol rather than a few large pools would be positive for the ecosystem.


Is to REALLY scale out the network is = more partially validating nodes, but fewer fully validating nodes?

That goes the opposite path of what you said below. Or might I have misunderstood?

https://bitcointalksearch.org/topic/m.53240986


Yes, scaling the network is adding more network participants, this is accomplished through scaling.


More participants partially validating, which won't be part of the whole network, and less participants fully validating is centralizing, making the network smaller. It is anti-scaling.

I think you should more holistically consider the meaning of centralization.  If I can't go to 7-11 and buy a coke with Bitcoin it is not fully decentralized.  If I need to have 3rd parties involved in a transaction it is not fully decentralized.  If I need to use centralized exchanges to trade with good liquidity it is not fully decentralized.  If it costs $200 to make a transaction it is pricing out network participants and small transactions which is not fully decentralized.

The more people that use Bitcoin, not just the number of people running nodes, is critical in answering the question of is it is decentralized.  Additionally, to have the largest network with the most particpants (most decentralized...?), I would argue that Bitcoin needs to scale on-chain.


But if you're willing to decrease the number nodes that are actually part of the network, that would be centralizing the protocol despite the number of users. That's scalng the network in, not out.

Then what are we here for? What's the point?


Growing node requirements/costs would only make node count go down, not up. Block Reduce might increase transaction throughput, but it's centralizing.


If there are benefits such as a greater number of users, and increased utility at a lower cost, the marginal degree of centralization (fewer fully validating nodes) may very well be worth it.  


More decentralized = more secure. It's better to over-shoot security than under-shoot it.

Quote

However, I would contend that with larger user base even if the cost of running a fully validating node increases, the absolute number of full nodes would likely go up not down even if the relative number shrinks.


That does not make sense.
member
Activity: 99
Merit: 91

Then I would debate that the statement, "allowing it to scale to handle tens of thousands of transactions per second without impacting fault tolerance or decentralization", is u true.


The actual effect on fault tolerance and decentralization has to be put into context that currently over 50% of Bitcoin's hashpower comes from only 4 pools.  As BlockReduce scales the node requirements to have a node which does partial state validation would be much less then a if Bitcoin scaled in its current state.  That would mean that although there may be fewer people validating full state, there will be more people, and fewer pools validating partial state. I would argue that having partially validating mining nodes is advantageous over having a deminimis number of pools.  Having smaller economic entities decide on the fate of the protocol rather than a few large pools would be positive for the ecosystem.


Is to REALLY scale out the network is = more partially validating nodes, but fewer fully validating nodes?

That goes the opposite path of what you said below. Or might I have misunderstood?

https://bitcointalksearch.org/topic/m.53240986


Yes, scaling the network is adding more network participants, this is accomplished through scaling.


More participants partially validating, which won't be part of the whole network, and less participants fully validating is centralizing, making the network smaller. It is anti-scaling.

I think you should more holistically consider the meaning of centralization.  If I can't go to 7-11 and buy a coke with Bitcoin it is not fully decentralized.  If I need to have 3rd parties involved in a transaction it is not fully decentralized.  If I need to use centralized exchanges to trade with good liquidity it is not fully decentralized.  If it costs $200 to make a transaction it is pricing out network participants and small transactions which is not fully decentralized.

The more people that use Bitcoin, not just the number of people running nodes, is critical in answering the question of is it is decentralized.  Additionally, to have the largest network with the most particpants (most decentralized...?), I would argue that Bitcoin needs to scale on-chain.


Growing node requirements/costs would only make node count go down, not up. Block Reduce might increase transaction throughput, but it's centralizing.


If there are benefits such as a greater number of users, and increased utility at a lower cost, the marginal degree of centralization (fewer fully validating nodes) may very well be worth it.  However, I would contend that with larger user base even if the cost of running a fully validating node increases, the absolute number of full nodes would likely go up not down even if the relative number shrinks.
legendary
Activity: 2898
Merit: 1823

Then I would debate that the statement, "allowing it to scale to handle tens of thousands of transactions per second without impacting fault tolerance or decentralization", is u true.


The actual effect on fault tolerance and decentralization has to be put into context that currently over 50% of Bitcoin's hashpower comes from only 4 pools.  As BlockReduce scales the node requirements to have a node which does partial state validation would be much less then a if Bitcoin scaled in its current state.  That would mean that although there may be fewer people validating full state, there will be more people, and fewer pools validating partial state. I would argue that having partially validating mining nodes is advantageous over having a deminimis number of pools.  Having smaller economic entities decide on the fate of the protocol rather than a few large pools would be positive for the ecosystem.


Is to REALLY scale out the network is = more partially validating nodes, but fewer fully validating nodes?

That goes the opposite path of what you said below. Or might I have misunderstood?

https://bitcointalksearch.org/topic/m.53240986


Yes, scaling the network is adding more network participants, this is accomplished through scaling.


More participants partially validating, which won't be part of the whole network, and less participants fully validating is centralizing, making the network smaller. It is anti-scaling.

Quote

The requirement that all market participants be fully validating nodes is a flaw not a virtue.  BlockReduce allows a larger number of incrementally more expensive ways of participating in the network while also scaling.


?

Growing node requirements/costs would only make node count go down, not up. Block Reduce might increase transaction throughput, but it's centralizing.
mda
member
Activity: 144
Merit: 13
Here is another idea along these lines for you

https://bitcointalksearch.org/topic/sharding-strategy-held-together-by-atomic-swaps-5109561.

It's basically a big package of altcoins with a built-in swapping mechanism where linear grow of block size leads to exponential grow of throughput.
member
Activity: 99
Merit: 91

Then I would debate that the statement, "allowing it to scale to handle tens of thousands of transactions per second without impacting fault tolerance or decentralization", is u true.


The actual effect on fault tolerance and decentralization has to be put into context that currently over 50% of Bitcoin's hashpower comes from only 4 pools.  As BlockReduce scales the node requirements to have a node which does partial state validation would be much less then a if Bitcoin scaled in its current state.  That would mean that although there may be fewer people validating full state, there will be more people, and fewer pools validating partial state. I would argue that having partially validating mining nodes is advantageous over having a deminimis number of pools.  Having smaller economic entities decide on the fate of the protocol rather than a few large pools would be positive for the ecosystem.


Is to REALLY scale out the network is = more partially validating nodes, but fewer fully validating nodes?

That goes the opposite path of what you said below. Or might I have misunderstood?

https://bitcointalksearch.org/topic/m.53240986


Yes, scaling the network is adding more network participants, this is accomplished through scaling.  The requirement that all market participants be fully validating nodes is a flaw not a virtue.  BlockReduce allows a larger number of incrementally more expensive ways of participating in the network while also scaling.  I think this is better than an all or nothing approach.  Additionally, when calculating market participants you should consider Bitcoin users in addition to nodes and miners as a metric of success.



legendary
Activity: 2898
Merit: 1823

Then I would debate that the statement, "allowing it to scale to handle tens of thousands of transactions per second without impacting fault tolerance or decentralization", is u true.


The actual effect on fault tolerance and decentralization has to be put into context that currently over 50% of Bitcoin's hashpower comes from only 4 pools.  As BlockReduce scales the node requirements to have a node which does partial state validation would be much less then a if Bitcoin scaled in its current state.  That would mean that although there may be fewer people validating full state, there will be more people, and fewer pools validating partial state. I would argue that having partially validating mining nodes is advantageous over having a deminimis number of pools.  Having smaller economic entities decide on the fate of the protocol rather than a few large pools would be positive for the ecosystem.


Is to REALLY scale out the network is = more partially validating nodes, but fewer fully validating nodes?


You don't believe that that will centralize Bitcoin toward the miners? Or you don't believe that users/economic majority should have the ability to run their own full nodes?


I think that people often times fall into tired narratives about majority of users, and fairness, et cetera without fully considering what any of it really means, or why it might be good or bad.  I would argue that if Bitcoin is meant to be censorship resistant and decentralized, that it must allow the greatest number of people to use it with the fewest intermediaries possible. Making low resource validation the primary focus of decentralization misses the point.  If even 20% of a population self custodianed Bitcoin which they regularly used for transactions it would be effectively impossible to censor or outlaw. When we discuss decentralization taking into account the power of the network which scales should also be a consideration, not just how easily it is validated.


That goes the opposite path of what you said below. Or might I have misunderstood?

https://bitcointalksearch.org/topic/m.53240986

Quote

Tromp, I appreciate the time that you have taken to look at BlockReduce.  One thing that I would debate is the use of the word sharding.  Although, a miner can depend upon a zone blocks work as an attestation to the correctness of the included transactions, they are not required to.  Much like an SPV node doesn't have to keep the entire chainstate but rather just looks at a block header.  This is not sharding per say, but rather a mode of operation that a node can work within to use less resources.  I would anticipate that serious miners or pools will run and validate full state because they have an economic incentive to do so, while merchants will likely run partial state much like SPV.  

member
Activity: 99
Merit: 91

Then I would debate that the statement, "allowing it to scale to handle tens of thousands of transactions per second without impacting fault tolerance or decentralization", is u true.


The actual effect on fault tolerance and decentralization has to be put into context that currently over 50% of Bitcoin's hashpower comes from only 4 pools.  As BlockReduce scales the node requirements to have a node which does partial state validation would be much less then a if Bitcoin scaled in its current state.  That would mean that although there may be fewer people validating full state, there will be more people, and fewer pools validating partial state. I would argue that having partially validating mining nodes is advantageous over having a deminimis number of pools.  Having smaller economic entities decide on the fate of the protocol rather than a few large pools would be positive for the ecosystem.


You don't believe that that will centralize Bitcoin toward the miners? Or you don't believe that users/economic majority should have the ability to run their own full nodes?


I think that people often times fall into tired narratives about majority of users, and fairness, et cetera without fully considering what any of it really means, or why it might be good or bad.  I would argue that if Bitcoin is meant to be censorship resistant and decentralized, that it must allow the greatest number of people to use it with the fewest intermediaries possible. Making low resource validation the primary focus of decentralization misses the point.  If even 20% of a population self custodianed Bitcoin which they regularly used for transactions it would be effectively impossible to censor or outlaw. When we discuss decentralization taking into account the power of the network which scales should also be a consideration, not just how easily it is validated.
member
Activity: 99
Merit: 91
Hi there! I was looking through some old research papers about merge-mining and came upon this thread. I'm very interested in your proposal as it seems like a great way to shard state without losing security via merge mining! I have a question for you though: If miners have to verify all the state that passes up to Prime, they have to run a full node so that they have the state of all the blockchains to properly verify everything. They are incentivized to do this so that they don't mine invalid blocks, but in doing so they might put a strain on the network because their zone and region nodes are not necessarily in the same geographic region as the rest of the zone and region nodes. (Of course, the zone that the miner is located in will be optimal, but I am talking about the rest of the zones and regions necessary for running a full state node).
For example, for n zones, n/2 regions, and m miners running a full state node, we have m - 1 latent nodes in each zone (or n*(m-1) latent zone nodes total) and m - 1 latent nodes in each region (or (n/2)*(m-1) latent region nodes total). Do you consider this an issue for network latency? Is there perhaps some way or incentive for a miner to run a full node and also run each sub-node (zone and region) in the proper geographic location? This might be physically difficult without the use of some cloud provider like AWS.

Looking forward to hearing more! Thanks.

Coopex, great question!  Sorry, it has taken me a bit to get back to you. The miner is incentivized to hold zone state which they are not mining because it reduces the risk they will include a zone block in a region block which eventually gets rolled back in the zone.  If they were to wait or delay including zone blocks in the region blocks, they could also achieve greater certainty, however they would get lower rewards.  Running the alternate zone state allows them to have greater certainty about a zone block faster.  Doing so with a node which is appropriately placed in the network topology will decrease that nodes latency and further decrease risk.  Therefore, miners will be incentivized to keep state and do so in a network optimal way.  I would absolutely expect that a person running full state would do so using something like AWS to allow optimization of the geographic placement of nodes.

Thanks for your response! I see now that miners are incentivized to run all of their nodes in the least latent way possible. However, miners might not physically be able to do so without moving their mining operation outside of the zone that they operate in, unless they want to pay a cloud provider to host it for them - which may not work if the cloud provider does not offer server hosting close enough or with proper precision to the geographic location of the zone. Perhaps a business could evolve to host servers in close proximity to every zone and move them around when necessary, kind of like high frequency trading does with the stock market, but even then you'd have the business be a centralizing factor.

In any case, my question is more general. Do you consider it an issue if some of the nodes in a zone are more latent than others? Are there bandwidth concerns with users or miners who run latent nodes? What if I just have a really shitty internet connection - could I be causing bandwidth issues for the network, or am I just causing issues for myself?

Thank you for your responses!

That is a pretty insightful question.  However, the answer is pretty simple.  With all distributed networks from things like Napster to Bitcoin you always have a seed and a leech problem.  In the example of Napster it is driven by storage space more than bandwidth.  In the context of Bitcoin it is driven by bandwidth more than storage.  Therefore, if you are a Bitcoin node that has low bandwidth you are slowing the overall network down (leech), whereas if you have high bandwidth you are speeding it up (seed).  BlockReduce is not different from Bitcoin in this regard. However, BlockReduce rewards mining in the zone chains creating an economic incentive for participants who are mining to optimize for latency.
legendary
Activity: 2898
Merit: 1823
This doesn't sound like "blockchain woo-woo" for you?  

https://github.com/mechanikalk/bips/blob/master/bip-%3F%3F%3F%3F.mediawiki

I'm not trying to troll/criticize, I'm trying to debate/learn. Because from what I have been told, "sharding" doesn't scale the network out, but only gives the impression that it's scaling out.

I had to look up woo woo on wikipedia where it's said to be "a term used by magician and skeptic James Randi to denote paranormal, supernatural and occult claims". I see no such claims in BlockReduce :-)

The proposal basically deals with the bandwidth problem of on-chain scaling, trading it off against trust that miners are doing the proper cross-shard checks that they're supposed and incentivized to. What it fails to do making the whole chain fully verifiable by a typical desktop computer, as should be apparent from "the total chain will require around 8 Tb/year of storage".


Then I would debate that the statement, "allowing it to scale to handle tens of thousands of transactions per second without impacting fault tolerance or decentralization", is u true.


The proposal basically deals with the bandwidth problem of on-chain scaling, trading it off against trust that miners are doing the proper cross-shard checks that they're supposed and incentivized to. What it fails to do making the whole chain fully verifiable by a typical desktop computer, as should be apparent from "the total chain will require around 8 Tb/year of storage".


Tromp, I appreciate the time that you have taken to look at BlockReduce.  One thing that I would debate is the use of the word sharding.  Although, a miner can depend upon a zone blocks work as an attestation to the correctness of the included transactions, they are not required to.  2Much like an SPV node doesn't have to keep the entire chainstate but rather just looks at a block header.  This is not sharding per say, but rather a mode of operation that a node can work within to use less resources.  I would anticipate that serious miners or pools will run and validate full state because they have an economic incentive to do so, while merchants will likely run partial state much like SPV


You don't believe that that will centralize Bitcoin toward the miners? Or you don't believe that users/economic majority should have the ability to run their own full nodes?
copper member
Activity: 9
Merit: 3
Hi there! I was looking through some old research papers about merge-mining and came upon this thread. I'm very interested in your proposal as it seems like a great way to shard state without losing security via merge mining! I have a question for you though: If miners have to verify all the state that passes up to Prime, they have to run a full node so that they have the state of all the blockchains to properly verify everything. They are incentivized to do this so that they don't mine invalid blocks, but in doing so they might put a strain on the network because their zone and region nodes are not necessarily in the same geographic region as the rest of the zone and region nodes. (Of course, the zone that the miner is located in will be optimal, but I am talking about the rest of the zones and regions necessary for running a full state node).
For example, for n zones, n/2 regions, and m miners running a full state node, we have m - 1 latent nodes in each zone (or n*(m-1) latent zone nodes total) and m - 1 latent nodes in each region (or (n/2)*(m-1) latent region nodes total). Do you consider this an issue for network latency? Is there perhaps some way or incentive for a miner to run a full node and also run each sub-node (zone and region) in the proper geographic location? This might be physically difficult without the use of some cloud provider like AWS.

Looking forward to hearing more! Thanks.

Coopex, great question!  Sorry, it has taken me a bit to get back to you. The miner is incentivized to hold zone state which they are not mining because it reduces the risk they will include a zone block in a region block which eventually gets rolled back in the zone.  If they were to wait or delay including zone blocks in the region blocks, they could also achieve greater certainty, however they would get lower rewards.  Running the alternate zone state allows them to have greater certainty about a zone block faster.  Doing so with a node which is appropriately placed in the network topology will decrease that nodes latency and further decrease risk.  Therefore, miners will be incentivized to keep state and do so in a network optimal way.  I would absolutely expect that a person running full state would do so using something like AWS to allow optimization of the geographic placement of nodes.

Thanks for your response! I see now that miners are incentivized to run all of their nodes in the least latent way possible. However, miners might not physically be able to do so without moving their mining operation outside of the zone that they operate in, unless they want to pay a cloud provider to host it for them - which may not work if the cloud provider does not offer server hosting close enough or with proper precision to the geographic location of the zone. Perhaps a business could evolve to host servers in close proximity to every zone and move them around when necessary, kind of like high frequency trading does with the stock market, but even then you'd have the business be a centralizing factor.

In any case, my question is more general. Do you consider it an issue if some of the nodes in a zone are more latent than others? Are there bandwidth concerns with users or miners who run latent nodes? What if I just have a really shitty internet connection - could I be causing bandwidth issues for the network, or am I just causing issues for myself?

Thank you for your responses!
member
Activity: 99
Merit: 91
Hi there! I was looking through some old research papers about merge-mining and came upon this thread. I'm very interested in your proposal as it seems like a great way to shard state without losing security via merge mining! I have a question for you though: If miners have to verify all the state that passes up to Prime, they have to run a full node so that they have the state of all the blockchains to properly verify everything. They are incentivized to do this so that they don't mine invalid blocks, but in doing so they might put a strain on the network because their zone and region nodes are not necessarily in the same geographic region as the rest of the zone and region nodes. (Of course, the zone that the miner is located in will be optimal, but I am talking about the rest of the zones and regions necessary for running a full state node).
For example, for n zones, n/2 regions, and m miners running a full state node, we have m - 1 latent nodes in each zone (or n*(m-1) latent zone nodes total) and m - 1 latent nodes in each region (or (n/2)*(m-1) latent region nodes total). Do you consider this an issue for network latency? Is there perhaps some way or incentive for a miner to run a full node and also run each sub-node (zone and region) in the proper geographic location? This might be physically difficult without the use of some cloud provider like AWS.

Looking forward to hearing more! Thanks.

Coopex, great question!  Sorry, it has taken me a bit to get back to you. The miner is incentivized to hold zone state which they are not mining because it reduces the risk they will include a zone block in a region block which eventually gets rolled back in the zone.  If they were to wait or delay including zone blocks in the region blocks, they could also achieve greater certainty, however they would get lower rewards.  Running the alternate zone state allows them to have greater certainty about a zone block faster.  Doing so with a node which is appropriately placed in the network topology will decrease that nodes latency and further decrease risk.  Therefore, miners will be incentivized to keep state and do so in a network optimal way.  I would absolutely expect that a person running full state would do so using something like AWS to allow optimization of the geographic placement of nodes.
member
Activity: 99
Merit: 91

The proposal basically deals with the bandwidth problem of on-chain scaling, trading it off against trust that miners are doing the proper cross-shard checks that they're supposed and incentivized to. What it fails to do making the whole chain fully verifiable by a typical desktop computer, as should be apparent from "the total chain will require around 8 Tb/year of storage".


Tromp, I appreciate the time that you have taken to look at BlockReduce.  One thing that I would debate is the use of the word sharding.  Although, a miner can depend upon a zone blocks work as an attestation to the correctness of the included transactions, they are not required to.  Much like an SPV node doesn't have to keep the entire chainstate but rather just looks at a block header.  This is not sharding per say, but rather a mode of operation that a node can work within to use less resources.  I would anticipate that serious miners or pools will run and validate full state because they have an economic incentive to do so, while merchants will likely run partial state much like SPV. 

Another way to think about BlockReduce is as a form of multi-level erlay where "sketches" are sent when a zone, or region block is found rather than an arbitrary delay.  The obvious difference being that actual sub-blocks are found which are rewarded to incentivize miners to self organize in a network optimal way.
legendary
Activity: 990
Merit: 1108
This doesn't sound like "blockchain woo-woo" for you?  

https://github.com/mechanikalk/bips/blob/master/bip-%3F%3F%3F%3F.mediawiki

I'm not trying to troll/criticize, I'm trying to debate/learn. Because from what I have been told, "sharding" doesn't scale the network out, but only gives the impression that it's scaling out.

I had to look up woo woo on wikipedia where it's said to be "a term used by magician and skeptic James Randi to denote paranormal, supernatural and occult claims". I see no such claims in BlockReduce :-)

The proposal basically deals with the bandwidth problem of on-chain scaling, trading it off against trust that miners are doing the proper cross-shard checks that they're supposed and incentivized to. What it fails to do making the whole chain fully verifiable by a typical desktop computer, as should be apparent from "the total chain will require around 8 Tb/year of storage".

I don't see these tradeoffs as being acceptable to the Bitcoin community, but they might appeal to the Ethereum community.
legendary
Activity: 2898
Merit: 1823
From your post-history, I see that you're a developer. What are your initial thoughts on OP's proposal?

The author appears knowledgeable and this may well be a sensible approach to sharding.
But personally I'm not a fan of sharding and its associated complexity increase.
It should appeal to Ethereum more than Bitcoin...


This doesn't sound like "blockchain woo-woo" for you?  

https://github.com/mechanikalk/bips/blob/master/bip-%3F%3F%3F%3F.mediawiki

Quote

BlockReduce is a new blockchain structure which only segments consistency, allowing it to scale to handle tens of thousands of transactions per second without impacting fault tolerance or decentralization.


I'm not trying to troll/criticize, I'm trying to debate/learn. Because from what I have been told, "sharding" doesn't scale the network out, but only gives the impression that it's scaling out.
legendary
Activity: 990
Merit: 1108
From your post-history, I see that you're a developer. What are your initial thoughts on OP's proposal?

The author appears knowledgeable and this may well be a sensible approach to sharding.
But personally I'm not a fan of sharding and its associated complexity increase.
It should appeal to Ethereum more than Bitcoin...
legendary
Activity: 2898
Merit: 1823
But just for clarification, what is "3+ orders of magnitude"? 3 times more?

No, 10^3=1000 time more. One order of magnitude is 10x.


From your post-history, I see that you're a developer. What are your initial thoughts on OP's proposal?
copper member
Activity: 9
Merit: 3
I'm lost. Include every quote for context please.

My bad, i did that because many users often complain about "pyramid quote"

I'm lost. Include every quote for context please.

But for you, you said that you would like OP's idea depending on the "ideology". What about technically?

It's vague question. Technically it's possible, but personally i wouldn't support the idea for Bitcoin.

I'm too stupid to know which ideas are viable or not. But if you ask me, the risks taken might not be worth the outcome.

gmaxwell, achow, comments?

But just for clarification, what is "3+ orders of magnitude"? 3 times more?

https://github.com/mechanikalk/bips/blob/master/bip-%3F%3F%3F%3F.mediawiki

Quote

BlockReduce presents a new blockchain topology that offers 3+ orders of magnitude improvement in transaction throughput while avoiding the introduction of hierarchical power structures and centralization.


I've read the paper and it certainly seems feasible. You can compare it to using mapreduce in a blockchain context. Of course the attack vector would increase but that's just how it is with complex cryptographic protocols - it's not something a few security audits and a team of smart engineers can't fix (and a testnet obviously). I don't think Bitcoin would take it on though because the changes would be too dramatic for the developers and the miners to accept - this probably needs to be a separate project unfortunately.
legendary
Activity: 990
Merit: 1108
But just for clarification, what is "3+ orders of magnitude"? 3 times more?

No, 10^3=1000 time more. One order of magnitude is 10x.
legendary
Activity: 2898
Merit: 1823
I'm lost. Include every quote for context please.

My bad, i did that because many users often complain about "pyramid quote"

I'm lost. Include every quote for context please.

But for you, you said that you would like OP's idea depending on the "ideology". What about technically?

It's vague question. Technically it's possible, but personally i wouldn't support the idea for Bitcoin.

I'm too stupid to know which ideas are viable or not. But if you ask me, the risks taken might not be worth the outcome.

gmaxwell, achow, comments?

But just for clarification, what is "3+ orders of magnitude"? 3 times more?

https://github.com/mechanikalk/bips/blob/master/bip-%3F%3F%3F%3F.mediawiki

Quote

BlockReduce presents a new blockchain topology that offers 3+ orders of magnitude improvement in transaction throughput while avoiding the introduction of hierarchical power structures and centralization.

Pages:
Jump to: