Bitcoin Forum
May 30, 2024, 01:51:11 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: YA solution: to preventing the 51% attack, improve scalability, etc,...  (Read 792 times)
erik777 (OP)
Sr. Member
****
Offline Offline

Activity: 504
Merit: 250


Earn with impressio.io


View Profile
January 15, 2014, 04:42:12 AM
Last edit: January 15, 2014, 04:55:54 AM by erik777
 #1

The solution to defending the integrity of bitcoin in the face of the potential 51% attack, and indeed the solution to many of bitcoin's issues, such as microtransactions, speed and scalability, will require P2P augmentation chains rather than a complete replacement of how the chain works today.  

By augmentation, I mean it is possible to add new concepts using P2P, but with separate chains that I'll call "secondary chains" to distinguish from the BTC chain.  For instance, let's say we want to reward highly distributed P2P mining more than centralized mining pools.  First, you create a new chain for validating distribution.  A miner joining the P2P chain becomes a part of this chain, which says that they contributed X to P2P mining.  That miner can cryptographically prove they contributed X.  

In doing so, when that miner creates a Bitcoin block, they can include that proof in the block as a reference to a secondary chain block, identifying that block as having been created by P2P mining, and, ultimately the quantity of that P2P mining pool determinable by the mining chain.  Central miners will not be able to add this proof.  

The Bitcoin reward system can be tweaked to calculate a different payout based on the distribution and decentralization of the mining pool that created the block.  Increased decentralization via P2P mining obtains a "bonus", whereas mining that is not able to provide distribution proof in the block pays a "tax".  The average payout remains the same, but now can vary to redistribute the tax to pay the bonus.  Thus, instead of 12.5 BTC per block, a miner proving to contribute to a highly distributed pool might get 13, while one lacking such proof might get 12.  The bonus/tax can be adjusted to satisfy a target distribution to decrease the possibility of a 51% attack.  
 
The trick in this particular augmentation is proving distribution and then tying it to mining work contributed.  

"Mining work contributed" can perhaps be hashing results that is successful with a lower difficulty that the current BTC target.  These smaller contributions can be signed onto the secondary chain.  The quantity of these transactions over a period of time can, at least in relative terms, determine the size of the pool.  

Yes, the lower level of difficulty suggests that it is more vulnerable.  The only thing is the secondary chain itself has no reward without the BTC chain.  So, it is only profitable to use your BTC hashes in the secondary chain.  You wouldn't dedicate separate computing power for it. 

Distribution is much harder to prove because nodes can be simulated.  I'd like to hear other people's thoughts on proving distribution.  These concepts that come to mind that, while not solid on their own, could be pieces of the solution:
 
  a> a trust network.  you trust yourself 100%.  you know when you are talking to 5 different nodes at 5 different public IP addresses (IPv6 could trash IPs as uniqueness, but this has value with IPv4 where there are only 4 billion and they are not cheap.)    

  b> you can verify a P2P pool does at least part of what it says it does to some extent by measuring it.  

  a+b>Thus, an individual that is contributing 1% to the pool can attest that at least 1% of the pools is what it says it is.  Those that trust this node have a 1% assurance.  This node expresses its assurance when it submits its mining work (that is less difficult than the BTC target) contributed to the secondary chain.  

  c> Nodes can broadcast physically measurable attributes specific their location.  Honestly, like shooting stars, I can shoot examples down as quickly as I can think of them.  

  d> We could consider stationary sites, like bitcointalk, that can become relay beacons for helping to verify distribution.  The trick is to ensure that the Internet beacons can be trusted to the extent that they cannot be simulated.  They don't have to be trusted as "honest" because cryptography can do the rest.  

  e> A peer validation scheme could help to identify that the P2P mining pool is distributed.  That is, you can reach out to nodes, who can attest to their contributions, thereby verifying that the pools is made up of real distributed contributors.  In fact, as I type, I'm liking this more than a through d combined.  The only limitation it is real-time, where people can verify the pool at any time, but I'm not sure how to cryptographically prove this.  I mean, I can run a scan and say, "yep, it looks legit".  But, then how do I get others to believe that I ran a legit scan and that the results proved that my sample was solid?    

I realize I've shifted the problem to proving distribution, and within that, proving that I've proven distribution.  But, on the plus side, I feel good about this analysis because I've concluded that secondary chains can augment the primary chain, and work contributed can be measured using hashes that are considered "successful" with a lower difficulty that the current BTC chain, and P2P network distribution can be proven with a degree of certainty in real-time via a sample peer discover scan.  That's three elements in this solution that are likely to provide some benefit.  

It's just that last part, proving that we've proven distribution, that is currently elusive.  Do we really need to quantify distribution? Are there alternatives such as simply proving pool size and isolation?  In the end, we just want to create a reward system that decreases as a pool approaches 51%, however we do it.  






.▄███     ██████     ███▄
██████   ███████   ██████
 ██████ ██████████ ██████
  ██████████████████████
   █████████  ████████
    ██████    ██████
    ███████    ██████
   █████████  █████████
  ██████████████████████
 ██████ ██████████ ██████
██████   ██████   ██████
 ▀███     ██████     ███▀
IMPRESSIO     ▄███████████████▄
     ██             ██
     ▀███████████████▀
           ██ ██
           ██ ██
       ▄▄█████████▄▄ ▄███▄
    ▄███▀▀       ▀▀████ ▀██▄
  ▄██▀   ▄▄█████▄▄   ▀██▄ ██
 ▄██  ▄███  █  █████▄  ██▄█▀
 ██  ███         █████  ██
██  ██████  ███   █████  ██
██  ██████  ▀▀▀  ▄█████  ██
██  ██████  ▄▄▄▄  █████  ██
██  ██████  ████   ████  ██
 ██  ███          ████  ██
 ▀██  ▀███  █  █████▀  ██▀
  ▀██▄   ▀▀█████▀▀   ▄██▀
    ▀███▄▄       ▄▄███▀
       ▀▀█████████▀▀
goode400
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile WWW
January 15, 2014, 08:03:54 AM
 #2

Refreshing to hear from someone who's actually proposing a way to solve the problem rather than just endlessly discussing that there is a problem.
empoweoqwj
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500


View Profile
January 15, 2014, 08:43:47 AM
 #3

Except the "solution" is amazingly over-engineered IMHO
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!