Info

Source on GitHub

https://github.com/5eraph/ts

Smart Contract Address

0:97344bd09ee1b3b84c2baee9f1c11df108928f2dc864937f88c50dcb015c66b9

Source on GitHub

https://github.com/5eraph/sw

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

1

Comments

Small Kitten Dec 23, 2019 at 20:44
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.
Small Kitten Dec 26, 2019 at 22:12
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.
You have not added any comments yet...
by rating

Issues

Clever Turkey Feb 11 at 02:39
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`.
1
Small Kitten Feb 12 at 16:44
Thank you for the feedback.

... (removed because of hard text limit :()

:::: edit 11022020 2111:
fixed: 2, 6, 5

:::: edit 12022020 1735:
all issues fixed to the possible extend
- proof of ownership - added note about consumer education and transparent data specification of data to be signed
- set available tickets - replaced with add available tickets - more predictible, but added notice about possible race conditions
- sw even as inefficient solution is meant as showcase solution with possible caching of DB. Implementation may and will varry based on provider needs and as such I leave this point unchanged but with notice in sw readme.

All other issues fixed to full extend. (Except minor query_id for cases when someone wants to identify query anyway)

Great job catching all my bugs. Thank you one more time
Nobody added any issues yet...