Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
RE: buying me and Gregory a shared beer: I would make a both of two btc-addresses script transaction using OP_EVAL. And post it. You would then not be able to know that you actually got a beer unless I told you so in a mail. But that transaction won't show up in my bitcoin wallet as bitcoins I can spend. And even if my wallet DID show me transactions that involve your keys but that you can't spend, all I would know is there are N bitcoins that I can only spend if I can somehow figure out that Gregory has public key XYZ. How would I know that unless you told me? I think the right long-term solution is moving away from bitcoin addresses as 'pay-to entity' and create an infrastructure where we're paying people or organizations. But in the short term, I think there are lots of benefits to creating a new type of bitcoin address built on top of OP_EVAL that will be very easy for all of our existing infrastructure to support. -- -- Gavin Andresen -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
OK, let me try to explain what I see is the problem: So far we the bitcoin addresses are (for all practical purposes) a one-to-one mapping between a pubkey and uint160. This mean that your wallet is defined solely by your privatekeys (from which you can extract pubkeys and then uint160 btc-addresses). This also enables you to make a uint160 to tx mapping on a server (like on blockexplorer) and use a thin client to query for transactions just from a list of uint160 (whether it holds the private keys behind them or not). In the case of a multisig transaction, lets say the 2of3 example, you could e.g. have all 3 corresponding uint160s but only one privkey, but still query the server and know the value of an asset of uint160s. This, I find a nice and clean setup, where cryptographic keys can be mapped to assets. If we now consider the OP_EVAL proposal. Here, a new use of the uint160, namely as a mapping of ripemd160(something extra and hash256(pubkey)) is introduced. This means that this clean mapping is broken. Your will have an extra public key being the something extra, and there is no easy way to do the mapping from a list of private keys to public keys to uint160s that will result in the new condensed uint160, except if you also have the knowledge of the script that was used. I agree that it will work and I (and bitcoin-js and blockexplorer) can of change the concept of a wallet to also include scripts, but it breaks an intrinsic logic of uint160s and transactions that has so far been quite nice and clean. So I also support checkmultisig to be the standard transaction type, but I do not appreciate the support of OP_EVAL. Cheers, Michael On 26/10/2011, at 17:00, Gavin Andresen wrote: On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager grona...@ceptacle.com wrote: I think it is a very important feature to be able to extract transaction to/from you only from your private keys. Why? If somebody is sending me bitcoins, then they'll have to get either an address or one or more public keys from me. OP_EVAL just lets me give them a short address that represents an arbitrary number of keys combined in an arbitrary way. I agree with Gregory: it shouldn't matter if that address is HASH(public key) or HASH(op_eval_script), the issues are the same (if you lose or cannot re-create the key/script then you're in trouble). Maybe I'm missing something; are you worried that blockexplorer won't know that coins sent to HASH(op_eval_script) are actually a complicated transaction until the coins are spent again? I'd consider that a feature, not a bug, because only the people involved in the transaction need to know the details until after the transaction is complete. Feel free to contact me about your 'tiered implementation for thin clients' -- I don't think OP_EVAL will make that significantly harder. I also agree with Alan: using OP_EVAL is not mandatory, I'm proposing that CHECKMULTISIG becomes a standard transaction type. -- -- Gavin Andresen Michael Gronager, PhD Owner Ceptacle / NDGF Director, NORDUnet A/S Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 62 14 01 E-mail: grona...@ceptacle.com -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
I think it is a very important feature to be able to extract transaction
to/from you only from your private keys. In the standard transactions this is
easily accomplished - in the case you only want to find the addr to tx mapping:
vectorpairopcodetype, vectorunsigned char vSolution;
if (!Solver(scriptPubKey, vSolution))
return 0;
BOOST_FOREACH(PAIRTYPE(opcodetype, vectorunsigned char) item, vSolution)
{
vectorunsigned char vchPubKey;
if (item.first == OP_PUBKEY)
// encode the pubkey into a hash160
return Hash160(item.second);
else if (item.first == OP_PUBKEYHASH)
return uint160(item.second);
}
This possibility is used today in:
* blockexplorer
* bitcoin-js
* my own tiered implementation for thin clients
I agree that you can of course always construct payment schemes to hide
payments (hashes from classic novels, sending the private key off line etc),
but I consider those either exotic or on purpose hidden, and hence they are not
really a problem, nor an argument that this feature does not really exist today.
So, if we introduce a standard (multikey) payment that hides the address (or
makes it overly complicated to extract it) it will be a major problem for the
projects that I listed above.
I will post a more detailed technical comment reflecting directly on the BIPs,
but the wiki is currently down and I need to re-read the BIPs first.
Cheers,
Michael
On 25/10/2011, at 18:47, Alan Reiner wrote:
On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen gavinandre...@gmail.com
wrote:
You give the hash to whoever is paying you, and store the hash --
script mapping when you do that (assuming you're not using a
deterministic wallet; if you are, you probably just increment a
counter in the wallet).
If anyone finds that solution unsatisfying, consider— It's already the
case that I could take one of your disclosed public keys and create an
infinite series of secondary keys out of it for which only you could
decode, and the only way for you to find them in the blockchain would
be to have performed the same procedure and made a note of the
addresses you're watching for.
(1) As I understand it, OP_EVAL is being proposed as an *optional* tool for
multi-signature transactions. It sounds like to me, that you can still use
the regular OP_CHECKMULTISIG if you are concerned about these things. If
you're dealing with too many parties with questionable reliability that they
will notify you of transacitons that include you, I don't see anything wrong
with declaring that you'd only prefer dealing with OP_CMS transactions and
not OP_EVAL (besides some grumbling from them that their way is better).
Either way, they're screwing themselves, too, if they want to include you on
transactions and don't notify you as such (kind of defeats the purpose of
multi-sig txs).
(2) I think it's unnecessary to discuss cases where you somehow lose your
mappings but not your private keys. In order for OP_EVAL scripts to work,
the subscripts/mappings are *just as important* as your regular private keys.
They should be kept in your wallet forever just like your private keys--and
thus you lose none of them or all of them. The only real difference is that
they aren't sensitive like your private keys, so they don't have to be
encrypted.
(3) There should most definitely be a button on the main client that allows
you to Add OP_EVAL script or something along those lines (maybe something
with a less obscure name). We need to make it as easy as possible for
someone to add such a script/mapping to their wallet. Although, this invites
a breach of one of my core rules of user interfaces: if the functionality is
dependent on the user performing some regular maintenance task, you better be
prepared for all users to fail at doing it. Even diligent users are going to
forget/mess-up sometimes. If failure at performing this task results in
breaking the client or losing money, we should avoid promoting that usage
paradigm.
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more
Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager grona...@ceptacle.com wrote: I think it is a very important feature to be able to extract transaction to/from you only from your private keys. In the standard transactions this is easily accomplished - in the case you only want to find the addr to tx mapping: The additional material _IS_ then part of the private key. It's not something seperate. Its something you need to know in order to author the address. This was fundamentally my argument. Not that you could hide information, but that information was already hidden. Right now under conventional uses I can't identify all the transactions that land in your wallet, because I don't know the keys it contains. With the proposal it's the same situation. This possibility is used today in: * blockexplorer * bitcoin-js * my own tiered implementation for thin clients [snip] So, if we introduce a standard (multikey) payment that hides the address (or makes it overly complicated to extract it) it will be a major problem for the projects that I listed above. These projects will be able to use the _same_ procedure to extract the identifying information. Except now instead of ripemd160(sha256(pubkey)) it will be more like ripemd160(sha256([some extra bytes generated by the wallet holder]||pubkey)) that you extract. If the former is not a problem for these applications, why is the latter? -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
scriptPubKeys that use OP_EVAL contain a hash of a script. If I understand correctly, that means to detect a transaction in a block that is relevant to your wallet, that means you need to pre-calculate every possible hash that might appear. For the case of a single payment, that's not a problem. It means for each key you now have to check for: - raw key - key hash - hash of script that contains key hash - hash of script that contains raw key which isn't so bad. What is the complexity like when multi-signing comes into the picture? I *think* it's not an issue for the use cases currently envisioned, but being unable to see into a script could complicate things later. Specifically: for a wallet protection service, you have to make sure the WPS keys are matched 1:1 with your own private keys. You must never mix them up otherwise you have to check the block chain for the cross-product. Deterministic wallets are one way to achieve that without compromising privacy. For escrow contracts, using OP_EVAL means you cannot detect them unless the sender has told you the pubkey they are going to use, because otherwise you can't recreate the hashed script. Escrow protocols require some out of band communication anyway in order to set up the escrow key, so this isn't inherently a problem. Are there any use cases where you will want to recognize transactions to you, where you can't predict the full script contents? -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
On Tue, Oct 25, 2011 at 6:49 AM, Mike Hearn m...@plan99.net wrote: scriptPubKeys that use OP_EVAL contain a hash of a script. If I understand correctly, that means to detect a transaction in a block that is relevant to your wallet, that means you need to pre-calculate every possible hash that might appear. You could do it that way... but that would be inefficient. You give the hash to whoever is paying you, and store the hash -- script mapping when you do that (assuming you're not using a deterministic wallet; if you are, you probably just increment a counter in the wallet). The only use case I can think of where you'd want to check for every possible hash is if you lose your wallet, you have a wallet backup that has your private keys in it, but DOES NOT have the hash -- script mapping(s). For use cases involving other people, that's probably not a problem-- you could ask them to tell you what public keys are involved, and then add them back in to the wallet (the RPC interface I settled on for m-of-n txns is an addmultisigaddress that takes the m and an array of n public keys, creates the script, adds the hash--script mapping to the wallet, and returns the hash). For use cases where all the keys belong to you... either a good, automatic, in-the-cloud-backup or the equivalent of -rescan is needed to recover in case the mappings are lost. -- -- Gavin Andresen -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen gavinandre...@gmail.com wrote: You give the hash to whoever is paying you, and store the hash -- script mapping when you do that (assuming you're not using a deterministic wallet; if you are, you probably just increment a counter in the wallet). If anyone finds that solution unsatisfying, consider— It's already the case that I could take one of your disclosed public keys and create an infinite series of secondary keys out of it for which only you could decode, and the only way for you to find them in the blockchain would be to have performed the same procedure and made a note of the addresses you're watching for. ... or really, more simply I could generate a private key on your behalf and send funds there. (What do you mean you didn't get the funds? I sent them to the private key defined by the cryptographic hash of the lyrics of your favorite song!) So it's already the case that if I didn't get your address from you (or through a negotiation with you), I can't expect you to receive them. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
