Bitcoin Forum
May 07, 2024, 12:26:59 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How all clients can switch to a p2p SPV system without decentralising Bitcoin!  (Read 1466 times)
bardi.harborow (OP)
Member
**
Offline Offline

Activity: 114
Merit: 10



View Profile
February 14, 2014, 06:11:23 AM
 #1

Centralisation - The dread of (almost) every Bitcoin user, but we are currently on track to do just that. Even the bitcoin.org website recommends a SPV client. So, I've done some thinking and have come up with as system that will allow the whole Bitcoin network to operate on a form of SPV network and still be decentralised. I'm not going to go into what SPV is. See Satoshi's white-paper for info. Here is my idea:

Each client will first download the headers, just like in Electrum, but with one crucial difference, it will download them fro a p2p network. After verifying them and working out the best tip, it will then begin to download some of the transactions. Notice I said "some". It will randomly download a percentage of the transactions (the percentage being set by the user, those who want to run full nodes download 100%, for example I might download 1%, about 130 MB). The transactions it gets will then be verified. If it finds invalid transactions it ignores the block and sends out an alert to the network. Then everyone in the network downloads the tx, verifies it, notices that it is invalid and discards the block.

Think of this as each node running random spot checks on transactions and raising the alarm if it finds a problem. People who download a percentage help support the network, and ensure that no transactions are ever lost.

The other idea I had was to use a bloom filter to notify peers of what txs you had (can somebody tell me whether that is a possibility?).

I believe this would require a new protocol to implement. Therefore, we would get bitcoind owners to run this as well to keep both networks synced.

Hope this is of interest, if so give me a yell and I'll start to get a dev team together (volunteers welcome).
1715084819
Hero Member
*
Offline Offline

Posts: 1715084819

View Profile Personal Message (Offline)

Ignore
1715084819
Reply with quote  #2

1715084819
Report to moderator
"Your bitcoin is secured in a way that is physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter a majority of miners, no matter what." -- Greg Maxwell
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715084819
Hero Member
*
Offline Offline

Posts: 1715084819

View Profile Personal Message (Offline)

Ignore
1715084819
Reply with quote  #2

1715084819
Report to moderator
d'aniel
Sr. Member
****
Offline Offline

Activity: 461
Merit: 251


View Profile
February 18, 2014, 06:07:11 AM
 #2

Nice, but not new ideas.

Here's the most recent thread on "fraud proofs": https://bitcointalk.org/index.php?topic=137933.0.

For "partial verification", we'd need TXO commitments by miners.  Mark Friedenbach (maaku) recently implemented authenticated prefix trees for this, and Peter Todd has proposed an alternative data structure -- a so called Merkle mountain range (MMR) -- that may be more efficient.
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1129


View Profile
February 18, 2014, 06:50:19 AM
 #3

SPV wallets already work the way you suggest. I first proposed Bloom filters in 2011 and they were implemented and launched at the start of 2013. These wallets (multibit/android/hive etc) already download the headers from the p2p network too.

So good thinking but I'd suggest doing more research before proposing other ideas that were already implemented years ago Smiley
bardi.harborow (OP)
Member
**
Offline Offline

Activity: 114
Merit: 10



View Profile
February 18, 2014, 07:31:17 AM
 #4

Nice, but not new ideas.

Here's the most recent thread on "fraud proofs": https://bitcointalk.org/index.php?topic=137933.0.

For "partial verification", we'd need TXO commitments by miners.  Mark Friedenbach (maaku) recently implemented authenticated prefix trees for this, and Peter Todd has proposed an alternative data structure -- a so called Merkle mountain range (MMR) -- that may be more efficient.

Can you clarify what you mean by "TXO commitments"? Can't we just have SPV clients do spot-checks (including tracing back to when the coin was generated) and if they find an invaild tx they send a invaild_alert(txhash) type alert?

SPV wallets already work the way you suggest. I first proposed Bloom filters in 2011 and they were implemented and launched at the start of 2013. These wallets (multibit/android/hive etc) already download the headers from the p2p network too.

So good thinking but I'd suggest doing more research before proposing other ideas that were already implemented years ago Smiley

Well that is embarrassing... I looked at the only SPV wallet that doesn't use a p2p network (electrum). When I mentioned merkle hashes I believe I was suggesting using them in a different way than currently but I could be wrong. Also, you didn't mention my "partial verification" idea (turns out someone stole it first, not maybe I can't call it my idea  Cry), my understanding is that has not been implemented (feel free to correct me).
d'aniel
Sr. Member
****
Offline Offline

Activity: 461
Merit: 251


View Profile
February 18, 2014, 08:17:22 AM
 #5

Can you clarify what you mean by "TXO commitments"? Can't we just have SPV clients do spot-checks (including tracing back to when the coin was generated) and if they find an invaild tx they send a invaild_alert(txhash) type alert?
In the authenticated prefix tree proposal, for example, a digest of the current set of unspent transaction outputs is included in each block, which enables short inclusion proofs.  This is similar to the usual Merkle tree of transactions included in each block, except more efficiently updated.  These would be needed to efficiently verify txins are valid, since you otherwise can't be sure they haven't already been spent without fully downloading every previous block.
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!