I don't know enough about zk-snarks to say if your method is good enough or not, but recently this bip-ZZZ ( https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki ) was published that I does what you want to achieve in an easier way IMO.
PUSHTXDATA type 15 is TXDATA_VOUT which for a specified output index, first pushes the amount that is being sent to the output, then the scriptPubKey which the amount is sent to. The type 3 pushes the amount in the input being redeemed.
So if you wanted a script that would always have to pay any amount sent to it to some pre-specified address, say mkqHTnuZ6icRzRms2fTyQU75fRqifpKFGb, you could program :
15 PUSHTXDATA 0x19 0x76A9143A501DE5E8B8A15856CD22A4BD9E5A1BE4C2E5AF88AC EQUALVERIFY 3 PUSHTXDATA EQUAL
Now if you fund this scriptpubkey, to use it as an input in some transaction, you must also include mkqHTnuZ6icRzRms2fTyQU75fRqifpKFGb in one of the outputs, and make sure that the amount in the utxo that you are redeeming is paid in full to that address.
I'm not even bothering with adding any checksigs or handling keys because the worst that could happen is that my address will get paid.
You could add more types of PUSHTXDATA and be a bit more clever with amount checks to even encode some pre-specified allowed fees (or hard code a subtraction of just *this* input and output's worth)
A cool post on the subject :
https://blockstream.com/2016/11/02/covenants-in-elements-alpha.html
Topic: ZK-SNARK to trustlessly automate wallets (Read 298 times)
I've been toying with the idea of autonomous bitcoin wallets. That is certain public key addresses that will always exhibit some behavior. A simple example might be a bitcoin wallet that always sends its entire contents to another pre-defined wallet every 24 hours.
In something like Ethereum this would be easy. Just create a smart contract. But say all parties insist on bitcoin, it's a little more challenging. Script is notably *not* Turing complete, so the complexity of possible pre-committed behaviors is pretty limited. However I still think autonomous wallets of arbitrary complexity can be created by using off-chain ZK-SNARKs. Here's how:
Alice wants to create an autonomous forwarding wallet like above. She writes a ZK-SNARK function, as an input it accepts a valid full block chain and the public key of a wallet. The function goes through the entire chain, consolidates all the existing transactions leading into the autonomous wallet, then outputs a transaction to send those to the pre-determined destination wallet. Alice publishes the function for anyone to inspect and test themselves.
Now Alice creates a public/private key conforming to the autonomous wallet. She cryptographically signs the above ZK-SNARK function, and provably destroys the private key. No one can generate transactions for the wallet besides the ZK-SNARK function. She publishes the signed function. If Bob wants to use the forwarding wallet, he can send BTC. Then Bob uses the function to generate a signed forwarding transaction, which he publishes to the network. As long as at least one person uses the ZK-SNARK function per block update, the wallet is guaranteed to forward its entire contents from the last block. If multiple people use the function, it's no issue. Duplicate transactions will do the same thing, and miners will just randomly pick one to add to the chain.
Advantages of this scheme: Most important, it allows for a lot more power than using Bitcoin Script. The autonomous wallets are Turing complete. It is run entirely off-chain, no need to shoehorn complex transaction logic into the limited transaction space that Bitcoin allows. If you want certain behavior, you don't have to wait for a BIP adding the needed opcode. Very complex systems can be evaluated only limited by the computing power of the users. It's completely trustless besides for the destruction of the private key. Anyone can inspect the function, and even run it on mock inputs (without signing the transactions).
Disadvantages: You have to trust that the private key was destroyed, otherwise Alice has backdoor access. Another disadvantage is it doesn't allow any state to be preserved between block updates, besides what's committed to the blockchain. This limits the possibility of persistence across times. One way to pass small amounts of data between block updates, would be to use encoded messages in the transaction. The generated outputs also need to be idempotent for each block update. If both Bob and Charlie run the function, the miners could arbitrarily pick which of their transaction to commit to the network. Finally it requires at least one person to run and publish the function per each block update, whereas Script is automatically processed within block updates.
So any opinions on this? I'm still a crypto-coin neophyte, so I could easily be making a mistake? Or am I re-inveting the wheel here? I couldn't find really any pre-existing literature on this specific topic. A lot of people talk about ZK-SNARKs for Ethereum or ZCash, but no one to create autonomous Bitcoin wallets or self-executing trustless Bitcoin contracts.
In something like Ethereum this would be easy. Just create a smart contract. But say all parties insist on bitcoin, it's a little more challenging. Script is notably *not* Turing complete, so the complexity of possible pre-committed behaviors is pretty limited. However I still think autonomous wallets of arbitrary complexity can be created by using off-chain ZK-SNARKs. Here's how:
Alice wants to create an autonomous forwarding wallet like above. She writes a ZK-SNARK function, as an input it accepts a valid full block chain and the public key of a wallet. The function goes through the entire chain, consolidates all the existing transactions leading into the autonomous wallet, then outputs a transaction to send those to the pre-determined destination wallet. Alice publishes the function for anyone to inspect and test themselves.
Now Alice creates a public/private key conforming to the autonomous wallet. She cryptographically signs the above ZK-SNARK function, and provably destroys the private key. No one can generate transactions for the wallet besides the ZK-SNARK function. She publishes the signed function. If Bob wants to use the forwarding wallet, he can send BTC. Then Bob uses the function to generate a signed forwarding transaction, which he publishes to the network. As long as at least one person uses the ZK-SNARK function per block update, the wallet is guaranteed to forward its entire contents from the last block. If multiple people use the function, it's no issue. Duplicate transactions will do the same thing, and miners will just randomly pick one to add to the chain.
Advantages of this scheme: Most important, it allows for a lot more power than using Bitcoin Script. The autonomous wallets are Turing complete. It is run entirely off-chain, no need to shoehorn complex transaction logic into the limited transaction space that Bitcoin allows. If you want certain behavior, you don't have to wait for a BIP adding the needed opcode. Very complex systems can be evaluated only limited by the computing power of the users. It's completely trustless besides for the destruction of the private key. Anyone can inspect the function, and even run it on mock inputs (without signing the transactions).
Disadvantages: You have to trust that the private key was destroyed, otherwise Alice has backdoor access. Another disadvantage is it doesn't allow any state to be preserved between block updates, besides what's committed to the blockchain. This limits the possibility of persistence across times. One way to pass small amounts of data between block updates, would be to use encoded messages in the transaction. The generated outputs also need to be idempotent for each block update. If both Bob and Charlie run the function, the miners could arbitrarily pick which of their transaction to commit to the network. Finally it requires at least one person to run and publish the function per each block update, whereas Script is automatically processed within block updates.
So any opinions on this? I'm still a crypto-coin neophyte, so I could easily be making a mistake? Or am I re-inveting the wheel here? I couldn't find really any pre-existing literature on this specific topic. A lot of people talk about ZK-SNARKs for Ethereum or ZCash, but no one to create autonomous Bitcoin wallets or self-executing trustless Bitcoin contracts.
Jump to: