Author

Topic: How all clients can switch to a p2p SPV system without decentralising Bitcoin! (Read 1488 times)

sr. member
Activity: 461
Merit: 251
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.
member
Activity: 114
Merit: 10
Nice, but not new ideas.

Here's the most recent thread on "fraud proofs": https://bitcointalksearch.org/topic/inflation-proofing-via-fraud-notices-137933.

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).
legendary
Activity: 1526
Merit: 1134
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
sr. member
Activity: 461
Merit: 251
Nice, but not new ideas.

Here's the most recent thread on "fraud proofs": https://bitcointalksearch.org/topic/inflation-proofing-via-fraud-notices-137933.

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.
member
Activity: 114
Merit: 10
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).
Jump to: