Re: [Bitcoin-development] Stealth Addresses

2014-03-06 Thread Dan Carter
I think stealth addresses combined with zk-snarks would obviate the need 
for CoinJoin.  zk-snarks could be used to hide the coin's value and 
stealth addresses could be used to hide the recipient for payments and 
even mined coins.  More info on zero-knowledge snarks:

http://cs.tau.ac.il/~tromer/papers/vnsnark-20131230.pdf
http://cs.tau.ac.il/~tromer/papers/csnark-20131007.pdf

Start with a mined coin: generate a coin secret, create a coinbase 
transaction with an output to your stealth address and send 
hash(coin-secret + reward-value) + encrypt(coin-secret + reward-value) 
where only the recipient (you) can decrypt. (The reward value is known 
publicly but just assume it isn't here for generality). You also embed 
the 0.2KB zk-snark proof + 3KB verifying key that the hash result is in 
fact SHA256(coin-secret + reward-value), where your private witnesses 
are (coin-secret, reward-value).

Now you could split a coin into as many pieces as you want in a single 
transaction and send to multiple recipients, some pieces go to yourself 
(change) and others to the payee, every piece would have a different 
recipient address thanks to stealth addresses, and all values hidden 
thanks to zk-snarks.

So lets say you want to split the mined coin into two new ones.  You 
create a transaction where the input redeems the mined coin using mined 
tx out + your stealth address, and there are two new coins as outputs to 
your own stealth address each having: hash(new-coin-secret + 
new-hidden-value) + encrypt(new-coin-secret + new-hidden-value).  You 
also embed the zk-snark proof that the two new hidden values add up to 
the original hidden value, and that the two new hash results are in fact 
SHA256(new-coin-secret + new-hidden-value), where your private witnesses 
are (original-coin-secret, original-hidden-value, new-coin-secrets, 
new-hidden-values).

If you want to merge two coins into one it's just a split backwards, two 
inputs one output, zk-snark proof that two original hidden values add up 
to the new hidden value and that the new hash result is 
SHA256(new-coin-secret + new-hidden-value).

If you want to transfer ownership of a coin then just redeem at input, 
and output same as mined coin except using recipient stealth address 
(which is a public key) to encrypt(coin-secret + hidden-value).

- Dan



On 2014-01-06 4:03 AM, Peter Todd wrote:
 * Abstract

 A Stealth Address is a new type of Bitcoin address and related
 scriptPubKey/transaction generation scheme that allowers payees to
 publish a single, fixed, address that payors can send funds efficiently,
 privately, reliably and non-interactively. Payors do not learn what
 other payments have been made to the stealth address, and third-parties
 learn nothing at all. (both subject to an adjustable anonymity set)


--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-12 Thread Dan Carter
I'm not sure how well this would work.

Sure it would provide honest historical pricing, but those who wait for 
publication confirmation may be at a disadvantage -- to get the best 
deal possible Bob would connect to as many nodes as he could, examine 
the stream of unconfirmed asks coming in and sign the best ones before 
someone else does.  The network would gravitate towards an O(n^2) fully 
connected network, because being fully connected means one is fully 
aware of all unconfirmed asks at any moment so one can make the best 
judgement and buy before someone else does.

The seller needs a guarantee that all bidders can act on the ask 
transaction simultaneously. Maybe the partial ask transaction could be 
time-locked with a network propagation delay, there would be multiple 
bidder responses and the winner is chosen by lottery (and fee priority) 
by the bitcoin/alt-coin miner who confirms the atomic transaction in 
their block.  That would eliminate the advantage to being fully 
connected as it would no longer matter that one can act first, so you 
have a more sane network.

On 2014-02-09 10:04 AM, Peter Todd wrote:
 Proof-of-publication(2) offers a solution. Alice can embed her
 incomplete transaction as data in a second, valid, transaction. She
 broadcasts this secondary transaction to some agreed upon blockchain,
 either the one the colored coin is in, or potentially a secondary system
 with suitable proof-of-publication security. Bidders such as Bob can now
 scan the blockchain for offers with an acceptable price. (the offers can
 make use of techniques like prefix filters to allow Bob to only scan
 part of the blockchain, although Bob needs to know the status of all
 assets of the type he is interested in anyway)


--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development