(taking this a bit out of order) On Thu, Oct 27, 2011 at 3:32 AM, Michael Grønager <grona...@ceptacle.com> wrote: > OK, let me try to explain what I see is the problem: [snip] > This, I find a nice and clean setup, where cryptographic keys can be mapped > to assets.
From my perspective that clean boundary remains: Functionally the script is part of the cryptographic key. [snip] > except if you also have the knowledge of the script that was used. Which you must. I can see no functional difference than if you said of the current system "except if you also have knowledge of the final 32 bits of the ECC private key". I don't see any reason to expect clients to identify funds without knowing the information required— it's impossible. I mean, sure, you _could_ bruteforce the final 32 bits of your private key— or you could attempt to try the cartesian product of every key you have with every key seen in the block chain for finding an op_eval script. But thats unworkable, unnecessary, equally bad for all client types, and not being suggested. Under either system a coin is not yours unless you know all of the right bits— knowing some is not good enough. Could you suggest how else we could gain the advantages of op_eval without it? How can I secure my wallet under whatever scheme I like— create a trust that requires multiparty signoff— and securely have senders pay into it without expecting them all to handle some rare and complicated procedure for sending to me? (Or a burdensome address which serializes a script and a large amount of data into hundreds of characters, and which still may be unable to represent the rules I wish to have govern my account— and which the sender might mutate— e.g. twiddling the threshold counts— and cause me great problems/confusion) [snip] > 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). [snip] > 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. On the basis of the discussion here I now oppose checkmultisig as a standard transaction type. (Sorry, I'm not trying to be a jerk if it came off that way, I'm not opposing it simply because you support it:) The advantage I saw of having it was faster deployment for the explicit escrow cases that don't need to encode the payment rules in an address (as is needed for wallet security and trusts)... but it seems to me that there is a serious misunderstanding that there is a bijection between hash160s and public keys, and one between ECC private keys and spendable transactions, and that this bijection is desirable or even essential to bitcoin. I'm concerned that this misunderstanding will moot the flexibility of the script system because every script that doesn't look like a direct mapping of hash160->pubkey->payee will be regarded as _broken_— not just useless to one app or another which could have simply chosen not to generate those addresses— but actually incompatible with bitcoin, as is basically being argued here— or, keeping in mind that people can freely mine non-standard transactions, could this result in tools which are rendered insecure by unexpected transaction types— Will a system that thinks HASH160 = IDENTITY recognize that a script which also requires an additional secret key on the stack is unspendable? Keeping checkmultisig alone as a standard transaction, when it's functionally a redundant subset of OP_EVAL (and inferior because it reduces the txn you can place in a block) could only further that misunderstanding. :-/ ------------------------------------------------------------------------------ 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
