1.1 The Message Data Structure of Bitcoin Transactions
Image can not upload ,if you don't not bitcoin Data Structure of Bitcoin Transactions you can read here:
http://bbs.dspay.org/forum.php?mod=viewthread&tid=17&extra=
CoinView
Transaction ID
Out1
Out2
Out3
…………
Transaction ID
Out1
…………………………
Transaction ID
Out1
…………………………
Transaction ID
Out1
…………………………
Transaction ID
Out1
Out2
……………………………………………………….
……………………………………………………….
The Bitcoin systems would create a cache file of all the transactions’ output (A file store in Levedb, taxon: CCoinView). When receiving a new block linking to the main chain, the system will check whether the all the transaction inputs of the block exist in the CCoinView or not. If not, the block will be judged as an illegal one and rejected by the system.
If exist, delete the spent output in the transactions and put in the new output. When the block fork and rollback happen due to the competition of hashing power or other reasons, it is also need to roll back the CCoinView.
Above algorithm run in all the Bitcoin system, which guarantee the uniqueness and traceability of Bitcoin payment, and effectively prevent double pay, counterfeit and replay attack.
1.2 The Data Structure of New Design
1. The Data Packet Structure of Transaction
source address
Public key of source address
destination address
transaction amount
tip
block height of sending
sign with the source address’ private key
Account View
Account ID
Balance
block height of last sending
Account ID
Balance
block height of last sending
Account ID
Balance
block height of last sending
Account ID
Balance
block height of last sending
Account ID
Balance
block height of last sending
……………………………………………………….
……………………………………………………….
Save the latest 1000 (can be set) block transaction
Transaction View
Transaction ID
location’s block height
Transaction ID
location’s block height
Transaction ID
location’s block height
Transaction ID
location’s block height
Transaction ID
location’s block height
……………………………………………………….
……………………………………………………….
No need to change the block structure, just save the transaction list.
Verification Process of the System:
Create a cache file of all the transaction’s output (Save in Levedb, taxon: AccountView). When receiving a new block linking to the main chain, system verifies all the transaction in the block. Below conditions will be rejected,
1. Source address not exist
2. Account View already has this transaction
3. Insufficient balance
4. Current block height is lower than “block height of sending”
5. Current block height is higher than “block height of sending” +1000
If there is no destination address, than add a new account.
1.3 FAQ
FAQ1. How to operate when rollback happen due to the hashing power competition?
ANS.: It’s same as Bitcoin, roll back block by block. Account View and Transaction View roll back at the same time. It will guarantee the data consistency.
FAQ2. How to prevent the replay attack?
ANS.: The replay attack can be prevented as every transaction contains the block height when sending; also 1000 latest transactions are cached. The unconfirmed transaction will be timeout after 1000 blocks, so it’s impossible to replay.
FAQ3. How to prevent the inflation of Account View?
ANS.: When the balance is less than a certain figure, or the account keeps sleeping longer than a certain period, it will be delete form the Account View. (The balance cannot use. When there is new income, it will be regarded as a new account.) The more users the system have, the bigger the view. However, it will never surpass the size of Bitcoin’s output CoinView.
FAQ4. About Anonymity
ANS.: After transaction complete, the currency can be change to another address if necessary. The anonymity will in the same level as Bitcoin.
Is there any bugs
??