fbe64037db
Merge pull request #35 from garious/split-benchmark
...
Move key generation and signing from transaction benchmark
2018-03-03 11:25:58 -07:00
d8c50b150c
Move key generation and signing from transaction benchmark
...
Key generation, signing and verification are not the performance
bottleneck. Something is probably wrong here.
2018-03-03 11:11:46 -07:00
8871bb2d8e
Merge pull request #30 from garious/simplify
...
Unify Claim and Transaction handling
2018-03-02 12:24:44 -07:00
a148454376
Update readme
2018-03-02 12:07:05 -07:00
be518b569b
Remove cyclic dependency between event and log
2018-03-02 12:03:59 -07:00
c998fbe2ae
Sign the owner's public key
...
Without this, the accountant will reject transfers from different
entities if they are for the same amount and to the same entity.
2018-03-02 11:56:42 -07:00
9f12cd0c09
Purge the Claim event type
...
It's now represented as a Transaction from an unknown party.
2018-03-02 11:48:58 -07:00
0d0fee1ca1
Sign Claim's 'to' field
...
Otherwise, the accountant will treat deposits of the same amount as
duplicates.
2018-03-02 11:46:22 -07:00
a0410c4677
Pipe all Claim constructors through a function
2018-03-02 10:58:43 -07:00
8fe464cfa3
Rename Claim's key field to match same field in Transaction
2018-03-02 10:47:21 -07:00
3e2d6d9e8b
Generalize Transaction to express a Claim
...
If a Transaction doesn't have an existing address, it's being used
to create new funds.
2018-03-02 10:41:15 -07:00
32d677787b
Reduce transactions sent by demo
...
We don't do retries yet, so keep tx count to something that won't
trigger any packet loss.
2018-03-02 10:35:38 -07:00
dfd1c4eab3
Don't process transaction if channel.send() fails.
...
Do all input validation first, then log (which can fail). If all
goes swimmingly, process the transaction.
2018-03-02 10:17:52 -07:00
36bb1f989d
More defense against a double-spend attack
...
Before this change, a client could spend funds before the accountant
processed a previous spend. With this change in place, the accountant
updates balances immediately, but that comes at an architectural cost.
The accountant now verifies signatures on behalf of the historian, so
that it can ensure logging will not fail.
2018-03-02 09:55:44 -07:00
684f4c59e0
Delete commented out code
...
accountant crate shouldn't verify the log. Instead, it should
only add valid entries and leave verification to network nodes.
2018-03-02 08:51:29 -07:00
1b77e8a69a
Move Event into its own crate
...
The log crate was starting to be the catch-all for all things
related to entries, events, signatures, and hashes. This split
shows us that:
* Event depends only on signatures, not on hashes [directly]
* All event testing was done via log testing (shame on me)
* Accounting depends only on events
2018-03-02 08:43:57 -07:00
662e10c3e0
Merge pull request #29 from garious/simplify
...
Remove Discovery event
2018-03-01 18:53:25 -07:00
c935fdb12f
Move signature duplicate detection into the historian
2018-03-01 17:44:10 -07:00
9e16937914
Delete the Discovery event
...
Not useful to the accountant.
2018-03-01 17:02:41 -07:00
f705202381
No need to hash data that's already hashed to create the signature
2018-03-01 16:39:09 -07:00
f5532ad9f7
Merge pull request #28 from garious/go-udp
...
Switch to UDP
2018-03-01 14:25:20 -07:00
570e71f050
Check for duplicate signatures
...
TODO: have client add recent hash to each message
2018-03-01 14:07:39 -07:00
c9cc4b4369
Switch to UDP from TCP
...
And remove all the sleep()'ing around.
2018-03-01 13:47:53 -07:00
7111aa3b18
Copy disclaimer from the loom repository
...
Per @aeyakovenko, added Loom's disclaimer.
2018-03-01 09:16:39 -07:00
12eba4bcc7
Merge pull request #26 from garious/add-accountant
...
Add testnode and client-demo
2018-02-28 19:48:05 -07:00
4610de8fdd
Switch to sync_channel to preserve order
2018-02-28 19:33:28 -07:00
3fcc2dd944
Add testnode
...
Fixes #20
2018-02-28 18:05:20 -07:00
8299bae2d4
Add accountant stub
2018-02-28 16:01:12 -07:00
604ccf7552
Add network interface for accountant
2018-02-28 14:00:04 -07:00
f3dd47948a
Merge pull request #25 from garious/verify-historian-input
...
Verify event signatures before adding log entries
2018-02-28 10:34:10 -07:00
c3bb207488
Verify event signatures before adding log entries
2018-02-28 10:23:01 -07:00
9009d1bfb3
Merge pull request #24 from garious/add-accountant
...
Add accountant
2018-02-27 11:41:40 -07:00
fa4d9e8bcb
Add more tests
2018-02-27 11:28:10 -07:00
34b77efc87
Sleep longer for TravisCI
2018-02-27 11:08:28 -07:00
5ca0ccbcd2
Add accountant
2018-02-27 10:54:06 -07:00
6aa4e52480
Merge pull request #23 from garious/add-transaction
...
Generalize the event log
2018-02-26 17:40:55 -07:00
f98e9a2ad7
Fix overuse of search-and-replace
2018-02-26 17:03:50 -07:00
c6134cc25b
Allow the historian to track ownership of any type of data
2018-02-26 17:01:22 -07:00
0443b39264
Allow event log to hold events of any serializable (hashable) type
2018-02-26 16:42:31 -07:00
8b0b8efbcb
Allow Entry to hold events of any kind of data
2018-02-26 15:37:33 -07:00
97449cee43
Allow events to hold any kind of data
2018-02-26 15:31:01 -07:00
ab5252c750
Move entry verification out of Entry impl
2018-02-26 14:39:01 -07:00
05a27cb34d
Merge pull request #22 from garious/add-transaction
...
Extend the event log with a Transaction event to transfer possession
2018-02-26 11:26:58 -07:00
b02eab57d2
Extend the event log with a Transaction event to transfer possession
...
This implementation assumes 'from' is the current owner of 'data'.
Once that's verified, the signature ensures that nobody modified
'data' (the asset being transferred) or 'to' the entity taking
ownership.
Fixes #14
2018-02-26 11:09:11 -07:00
b8d52cc3e4
Make the Discovery event into a struct instead of a tuple
2018-02-24 11:15:03 -07:00
7d9bab9508
Update rendered demo diagram
2018-02-24 11:09:00 -07:00
944181a30e
Version bump
2018-02-24 11:06:08 -07:00
d8dd50505a
Merge pull request #21 from garious/add-signatures
...
Add signatures
2018-02-24 10:47:25 -07:00
d78082f5e4
Test bad signature
2018-02-24 10:27:51 -07:00
08e501e57b
Extend the event log with a Claim event to claim possession
...
Unlike a Discovery event, a Claim event associates a public key
with a hash. It's intended to to be used to claim ownership of
some hashable data. For example, a graphic designer could claim
copyright by hashing some image they created, signing it with
their private key, and publishing the hash-signature pair via
the historian. If someone else tries to claim it as their own,
the designer can point to the historian's log as cryptographically
secure evidence that the designer's copy existed before anyone
else's.
Note there's nothing here that verifies the first claim is the actual
content owner, only that the first claim almost certainly happened
before a second.
2018-02-24 10:09:49 -07:00
