Re: [Bitcoin-development] Fidelity-bonded ledgers
On Mon, Feb 25, 2013 at 09:44:58PM -0500, Peter Todd wrote: > Lets suppose we take away everything but the transaction/scripting One last thing: credit goes to Gregory Maxwell for his ideas about adding unspent-chaum-token redemption op-codes to Bitcoin proper that lead me down the path to the more general Fidelity-Bonded Ledger idea. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fidelity-bonded ledgers
Lets suppose we take away everything but the transaction/scripting
system from Bitcoin. What is left is basically a way for to prove that a
set of pubkeys authorized the movement of coins from one place to
another. Of course, such a system is flawed as a currency because of the
double spend problem - specifically the need to know that there exists
global consensus on what particular set of transactions is the accepted
state.
However, in the event that a party commits double-spend fraud, it is
trivial to prove to others that they did so. Thus if a way to punish
that party can be found, we can give them an incentive to behave
honestly.
Consider the following new opcode and scriptPubKey:
n m CHECK_DOUBLE_SPEND_PROOF
spent with the following scriptSig:
{transaction 1} {transaction 2}
where where both transactions are part of the block chain starting at
the given genesis hash, and whose blocks are signed by n of m ledger
pubkeys; the ledger is the entity entrusted to keep the ledger accurate
and not allow double-spends to occur.
Anyone with proof of a double-spend attempt made in the blockchain
starting at a given genesis hash can collect a reward. In essence, the
txout is the fidelity bond holding the ledger accountable.
Of course, the devil's in the details...
Transactions and blocks
---
Transactions themselves can follow the Bitcoin system of scripts,
scriptPubKeys, and scriptSigs and re-use the existing validation
machinery.
A so-called block however is reduced to the simpliest possible form:
where the signatures are that of the ledger. The block hash is optional
and provides a way to further link a block into some sort of system to
make double-spend fraud detectable. Importantly the Bitcoin validation
machinery itself only needs to know that the double-spend happened at
all, not how it was detected.
Note how had the string manipulation opcodes not been disabled, in
particular SUBSTR, and had CHECKSIG not been designed as a single
opcode, it might have even been possible to create the double-spend
detector using the existing scripting system. Equally with just a set of
ECDSA opcodes one could probably construct a double-spend detector using
non-Bitcoin compatible transactions, but alas, things didn't work out
that way.
Moving funds in and out of fidelity-bonded ledgers
--
First the depositor informs the ledger of the amount they wish to
deposit, and one txin that will be used for that deposit.
Nex the ledger first creates a ledger-only transaction with the the
following scriptPubKey:
CHECK_PAYMENT
VERIFY CHECKSIG
spendable with the following scriptSig:
The CHECK_PAYMENT opcode returns true if provided with a proof that a
transaction with a txout of the correct value and scriptPubKey spending
the given txin exists in the Bitcoin blockchain. The ledger should
ensure that a different scriptSig is created for every deposit. The txin
is provided to allow the ledger to use the same scriptPubKey for all
deposits and thus make external audits easier. (note that an UTXO merkle
sum proof system is most likely to index by scriptPubKey)
The ledger gives the depositor the fully signed transaction, and the
depositor makes it valid by broadcasting that transaction and getting it
confirmed in the block chain.
Withdrawls from the ledger to the blockchain proper can happen the same
way, but this time it's the ledger that provides the transaction, and
the transaction owner that spends the transaction to an address of the
ledger's choosing.
Detecting double-spends
---
From the point of view of the Bitcoin validation machinery, double-spend
detection is undefined. Thus multiple systems are possible without
changing the validation rules.
One simple method would be for the ledger to maintain a publicly
accessible website, in particular publically accessible over Tor.
Transactions would be incorporated into a single log, and clients would
expect to be able to get copies of that log at any time anonymously. If
their transaction did not appear in the log, they could immediately
prove the double spend. (going as far back as the genesis block) The
optional block hash signed by every transaction would be incorporated
into the audit logs.
Equally trusted computing technologies can also be used instead of, or
in conjunction with, the ledger audit logs.
Ensuring the bond can-not be collected by the ledger
The simplistic scriptPubKey presented in the introduction allows for the
ledger to create their own fraud proof and run with the funds. What we
actually need is a way to constrain the destination of those spend
funds. Consider the following scriptPubKey:
{bond ops omitted} GET_TXOUTS HASH160 EQUAL
GET_TXOUTS would put a serialized version of each scriptPubKey, value,
and so on on the stack. (ideally using the existing CHECKSIG
Re: [Bitcoin-development] Key retirement and key compromise
We've been toying with the idea of a 'dead' button, one that issues a bunch of pre-generated txs sending stuff out to a previously secured 'backup' set of addresses (we don't think in terms of wallets, just keypairs). In this scenario, you have a long-term storage address (or set of them), and if you need to hit the panic button, previously signed transactions send value over to your emergency storage. If you've mucked around sending / receiving with your long-term storage, you'd only catch some BTC, not necessarily all, but what's nice is the panic transaction leaking has lower security requirements than your private keys -- worst case it's out, and you've got to deal with stuff in emergency storage, as opposed to losing all your coins. You could pair this with a server that checks if 'safe' addresses have 'unauthorized' transactions showing up on the blockchain, and you'd have a reasonable automated security layer. Maybe. :) I'm interested in thoughts on this approach as well. Jorge -- I respectfully disagree with you, there are a number of enterprise scenarios where your method is not appropriate. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Key retirement and key compromise
Just create a new wallet and send everything to a new address. I don't think additional tools for this are needed. On 2/23/13, Roy Badami wrote: > Has anyone been thinking about providing tools to allow users to cope > with key compromise - or more generally, to manage key retirement etc? > > atm, if you suspect that your keys may be liable to compromise then > what would you have to do? You'd have to create a new wallet (on a > new computer? or is it easy to have two coexisting installs on one > computer?) And then you'd have to make one or more payments from the > old wallet to the new wallet, to transfer the coins. It's a pain, and > you've lost your address book, your transaction history, etc. And > unless you keep the old wallet about, too, you're a bit stuck if > someone makes a payment to one of the old addresses. It's something > that most users would baulk at unless they're really sure they're at > significant risk. > > Of course, there are a spectrum of scenarios, ranging from having an > unencrypted wallet stolen by someone who knows what it is, through to > deciding that the passphrase you used to use when you only had a few > dollars worth of BTC maybe isn't good enough now you've got tens of > thousands of dollars worth of coins. Or maybe you have no reason to > suspect there is a risk of compromise, but just have a corporate key > management policy that recommends retiring keys after a period of > time. > > What would be really nice is for bitcoin to have a big key compromise > button, which would automatically transfer all coins to newly > generated addresses (optionally with a pause between generation and > transaction - to allow for a new wallet backup). Optionally, too, the > compromised/retired addresses could be marked with a flag such that if > someone sends coins to that address bitcoind immediately generates a > transaction to transfer the coins to address(es) which are good. > > I know deterministic wallets have many proponents - but personally I > like having a bag of keys - with the idea that over a period of time, > old keys will routinely be retired and their balances automatically > transfered to newly generated keys. If someone really manages to > crack the passphrase on that 10-year-old wallet backup they got hold > of, then if would be nice to minimise the damage they could do... > > And, of course, I want a big panic button that allows me to > automatically transfer all my coins to new addresses ASAP if I > suddenly do something stupid, like accidentally type my passphrase > into my IRC window :-) > > Thoughts? Is this functionality that there is any interest in > developing within the official client? If there is any interest in > this then obviously the first step would be to specify exactly what > functionality is wanted... > > roy > > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Jorge Timón http://freico.in/ http://archive.ripple-project.org/ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
