SPV idea up for discussion

[xeroc]

When I was in Amsterdam, I've had these thoughts that wouldn't let me rest until it made sense to me. So i stripped the thoughts apart and tried tackling them one at a time. The first thought that I finally got to put down in written is about SPV (Simple payment verification - the term doesn't fit well, but is known in the space). I wrote it all down in the bitshares-core wiki:

https://github.com/bitshares/bitshares-core/wiki/SPV

Given that discussion are best held via issues, I thought I should maybe put it here too.
Please feel free to edit/extend the wiki directly if you feel you can contribute there.

User Story
I want to be able to prove outside the BitShares Blockchain that a transaction is part of the blockchain with only little additional data provide (not the entire chain)

Impacts
Describe which portion(s) of BitShares Core may be impacted by your request. Please tick at least one box.

• API (the application programming interface)
• Build (the build process or something prior to compiled code)
• CLI (the command line wallet)
• Deployment (the deployment process after building such as Docker, Travis, etc.)
• DEX (the Decentralized EXchange, market engine, etc.)
• P2P (the peer-to-peer network for transaction/block propagation)
• Performance (system or user efficiency, etc.)
• Protocol (the blockchain logic, consensus, validation, etc.)
• Security (the security of system or user data, etc.)
• UX (the User Experience)
• Other (please add below)

CORE TEAM TASK LIST

• Evaluate / Prioritize Feature Request
• Refine User Stories / Requirements
• Define Test Cases
• Design / Develop Solution
• Perform QA/Testing
• Update Documentation

[pmconrad]

Interesting.

The biggest problem I see is that in a maintenance interval 1/3+1 (or more) of the witnesses can change. In an extreme case, this can lead to two equally valid chains, each with support from 2/3+1 of their witnesses.

I think until we have solved that problem you cannot prove legitimacy of a given set of witnesses with signatures from that same set of witnesses.

See related discussions in #831, #884.

[ryanRfox]

Thank you for capturing your thoughts here. I look forward to iterating on possible SPV solutions. Keeping track of the authoritative set of block signing keys is the basis for our discussion. I feel we need to define a method to guard against changes to the block producing set impacting the ability to maintain an authoritative set resulting from voting. Likely this will require limiting how many block producers may be allowed to be added or removed from the legacy set over time.

If we can define which block producers had authority to sign a block containing a given transaction, we can then explore separating the signature from the transaction data (SEGWIT). I feel the signature need only be retained in memory until reaching last irreversible block (LIB), thus representing validation that the signature was observed and validated by the then active authoritative block producer set. This change will reduce our overall block size, as they will continue to contain all operations, but only a merkle proof of the observed signatures.

[xeroc]

@pmconrad You are right, I forgot to mention that the max number of witnesses that can change per maintenance has to be limited to a CONSTANT (say, 1)

[xeroc]

@ryanRfox good thought about segwit. Need to research think about it.

[clockworkgr]

steemit/steem#812

[xeroc]

steemit/steem#812

Difference to steem is that BitShares has a maintenance interval and witnesses only change there!
With that, we have an additional "slotting":

• Blocks - currently every 3 seconds
• Rounds - currently about every 80 seconds
• Maintenance - currently every 86400 (24hrs)

For SPV, you need to obtain all data that is required to verify block producers. Hence,

• the list of valid block producers every 24hrs
• the order of block producers every ~80seconds

The latter point can (maybe) neglected when we make use of irreversibility and/or BFT so that we require witnesses to explicitly commit to (or approve) a special block. We can reuse some of the "slotting" to require this kind of confirmation/commitment, e.g. ask witnesses to commit to the first block of the previous round by approving the 1st block in the new round.

[ryanRfox]

I'm going to add this to (next) Protocol Release for Core Team to discuss further.