If such/similar model was posted elsewhere, please let me know. If it's shitty please post arguments, I'll happily send
Edit: ~bounty
Topic: Blind bookkeeper and his wife (Read 1085 times)
The objective is to minimize trust needed for service provider and transfer this trust on infrastructure provider (the privacy policy and the ensuing reputation he may lose, his QOS also) and the software. While software isn't a problem I guess(at least not world-bank soft., just for limited community), the infrastructure provider part is harder to achieve. Can we create Amazon EC2 instance and be sure that admin won't have access to its internal data and so to its private keys? If yes, than relying on same infrastructure place second instance in different region and let master sync balances with this new slave and let them both go to the PANIC mode if something went wrong. I think those pairs should have short lifetime, a week or even a day. Maybe significant part of same software should run in public balances mode that can be audited by everyone.
If such/similar model was posted elsewhere, please let me know. If it's shitty please post arguments, I'll happily send0.1 0.02 BTC to one who will show its suckness(language and naming excluded), even in few lines. Thanks!
Edit: ~bounty
If such/similar model was posted elsewhere, please let me know. If it's shitty please post arguments, I'll happily send
Edit: ~bounty
Hi All,
While searching for off-the-chain BTC txs I came up with small and simple idea that I want to share and discuss:
Set up two machines, master and slave - bookkeeper and wife, bookkeeper will make basic accounting, his wife will scream loudly if he pass out or he lost hist mind. Tech side:
1. Two instances running in cloud with good reputation.
2. Instance images are closed to any internal administration (no ssh... cpanel hehe), only transactions and bookkeeper-wife communication and btc network, both publicly(or widely) auditable. Configured with no persistent storage so any reboot or hardware failure will lead to erasing all instance data.
3. Bookkeeper's software, running in ramdisk, creates keypairs at startup, receives BTC via network, creates user account (tied to sender btc address) credited with received coins and takes account creation fee. Then user can register another accounts(with fee) or transfer some coins to other accounts. There is no transactions history at his side, all done with atomic balance updates.
4. Along with each BTC network deposit, bookkeeper appends new input to private transaction.
5. When sender-receiver(internal) balances change - private transaction's outputs matching their balances are updated.
6. After each priv-tx update, priv-tx is immediately send to second instance - bookkeeper's wife.
7. Private transaction is broadcasted to btc network in three cases:
a) publicly known and agreed bookkeper's end-of-life is reached (bkkeeper broadcasts)
b) bookkeeper unexpectedly died, or at least he stopped responding to his wife (wife broadcasts)
c) wife is dead or got mad (bkkeeper broadcasts)
8. If all instances job was done good (7.a) the final transaction contains also output for instance holder to collect fees (so there are actually two priv-txs kept whole time, one with fees to the admin and one without)
Both instances should be hosted by different providers or at least at different zones, then the probability that the priv-tx won't be broadcasted(all btc would be lost then) is minimal.
This simple model should be very useful for small communities but surely can scale up and get additional layers to match other use cases. And there is no transactions history at all (of course bookkeeper can work with one in his RAM).
Needed parts are:
- reliable software
- cloud provider matching needs(stable, instance audits, data privacy)
So, what do you think about it?
P.S. Sorry for my ~English
----
Here is first sketch, in Java
https://github.com/kactech/offchain/blob/master/blind-bookkeeper/src/main/java/com/kactech/offchain/BlindBookkeeper.java
---
2013-07-24 - sketch update
While searching for off-the-chain BTC txs I came up with small and simple idea that I want to share and discuss:
Set up two machines, master and slave - bookkeeper and wife, bookkeeper will make basic accounting, his wife will scream loudly if he pass out or he lost hist mind. Tech side:
1. Two instances running in cloud with good reputation.
2. Instance images are closed to any internal administration (no ssh... cpanel hehe), only transactions and bookkeeper-wife communication and btc network, both publicly(or widely) auditable. Configured with no persistent storage so any reboot or hardware failure will lead to erasing all instance data.
3. Bookkeeper's software, running in ramdisk, creates keypairs at startup, receives BTC via network, creates user account (tied to sender btc address) credited with received coins and takes account creation fee. Then user can register another accounts(with fee) or transfer some coins to other accounts. There is no transactions history at his side, all done with atomic balance updates.
4. Along with each BTC network deposit, bookkeeper appends new input to private transaction.
5. When sender-receiver(internal) balances change - private transaction's outputs matching their balances are updated.
6. After each priv-tx update, priv-tx is immediately send to second instance - bookkeeper's wife.
7. Private transaction is broadcasted to btc network in three cases:
a) publicly known and agreed bookkeper's end-of-life is reached (bkkeeper broadcasts)
b) bookkeeper unexpectedly died, or at least he stopped responding to his wife (wife broadcasts)
c) wife is dead or got mad (bkkeeper broadcasts)
8. If all instances job was done good (7.a) the final transaction contains also output for instance holder to collect fees (so there are actually two priv-txs kept whole time, one with fees to the admin and one without)
Both instances should be hosted by different providers or at least at different zones, then the probability that the priv-tx won't be broadcasted(all btc would be lost then) is minimal.
This simple model should be very useful for small communities but surely can scale up and get additional layers to match other use cases. And there is no transactions history at all (of course bookkeeper can work with one in his RAM).
Needed parts are:
- reliable software
- cloud provider matching needs(stable, instance audits, data privacy)
So, what do you think about it?
P.S. Sorry for my ~English
----
Here is first sketch, in Java
https://github.com/kactech/offchain/blob/master/blind-bookkeeper/src/main/java/com/kactech/offchain/BlindBookkeeper.java
---
2013-07-24 - sketch update
Jump to: