Info
Source on GitHub
Smart Contract Address
0:97344bd09ee1b3b84c2baee9f1c11df108928f2dc864937f88c50dcb015c66b9
Source on GitHub
Smart Contract Address
0:54f31b12814165f64b564e51d351e4e04ac0a990a764c3ac0315221cbdda8f82
Testing and Issues
You can test this entry and submit issues during the testing period of the Blockchain Contest, Stage 2 contest.
Entries with serious issues will not be able to win the contest, but even minor issues might be important for overall results.
Voting
Comments
1. Event Ticket system to support event indrustry. (Cryptography & blockchain driven ticket sells and verification workflows.)
2. SoftWare registry for per company/per developer origin verification.
2. SoftWare registry for per company/per developer origin verification.
TS provides buy, refund and transfer methods for customers as internal messages and basic control for contract owner through external messages.
Some parts are intentionally not editable after contract deployment even though it is easy to make it possible. E.g. price. The reason for this is to prevent potential issues with refunds as when you set refunds 100% and increase price over time, what would result in net profit for customer and loss for you. Implementation of safe price change would require much more storage and increase complexity.
SW is relatively simple contract controlled only by its owner. It exposes list of valid SW hashes to potential consumer as integrity/security checks. Aims to provide distributed and secure hash registry. Of course it can be used either as black list or white list. But primary intention was white list - list of hashes of distributed binaries.
Some parts are intentionally not editable after contract deployment even though it is easy to make it possible. E.g. price. The reason for this is to prevent potential issues with refunds as when you set refunds 100% and increase price over time, what would result in net profit for customer and loss for you. Implementation of safe price change would require much more storage and increase complexity.
SW is relatively simple contract controlled only by its owner. It exposes list of valid SW hashes to potential consumer as integrity/security checks. Aims to provide distributed and secure hash registry. Of course it can be used either as black list or white list. But primary intention was white list - list of hashes of distributed binaries.
You have not added any comments yet...
by rating
Issues
We found some issues in your contracts.
Critical:
- There is a race between "set available_tickets" external query and tickets buying/refunding. There is no way to set a correct value, while others also change value of `available_tickets`.
- It is possible to buy 0 tickets, effectively draining contract funds.
- If all tickets was transferred/refunded, seq_no is dropped, so replay of the transfer/refund is possible in the future.
- The one-time code for proof_ownership and transfer/refund queries are signed by the same key, so owner can be tricked to sign a query instead of a random one-time code.
- In the Software contract owner can overflow seq_no with op == 0, because seq_no resetting is not implemented for this op.
- In the Event Ticket contract `query_seq` is reset, but `seq + 1` is set , so after 65536 external message the contract will be unusable.
- The Software contract provides an inefficient solution for the problem. The better solution is to sign files and store only revoked non-expired signatures in the blockchain.
Minor:
- `query_id` can be replaced with 32-bit `valid_until`.
Critical:
- There is a race between "set available_tickets" external query and tickets buying/refunding. There is no way to set a correct value, while others also change value of `available_tickets`.
- It is possible to buy 0 tickets, effectively draining contract funds.
- If all tickets was transferred/refunded, seq_no is dropped, so replay of the transfer/refund is possible in the future.
- The one-time code for proof_ownership and transfer/refund queries are signed by the same key, so owner can be tricked to sign a query instead of a random one-time code.
- In the Software contract owner can overflow seq_no with op == 0, because seq_no resetting is not implemented for this op.
- In the Event Ticket contract `query_seq` is reset, but `seq + 1` is set , so after 65536 external message the contract will be unusable.
- The Software contract provides an inefficient solution for the problem. The better solution is to sign files and store only revoked non-expired signatures in the blockchain.
Minor:
- `query_id` can be replaced with 32-bit `valid_until`.
Nobody added any issues yet...