Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen: >> So my first shot at this is to go through the inputs of a transaction and >> see if the scriptSig field has only two opcodes. If that is the case, I assume that it is of the structure <sig> <pubKey> and calculate the Bitcoin address from <pubKey>. >> But then I started to wonder if this is safe. Can this be tricked somehow? > > Sure. There are lots of non-standard scriptPubKey scripts that will validate if given <sig> <pubKey> as input: a simple OP_NOP would work (do nothing, then check the top value on the stack and validate if it is not zero-- and <pubKey> is not zero).
Aw, I see. So back to the drawing board for me. How about this: I make sure that <sig> is a proper signature from a green address key, by bringing my own scriptPubKey of just OP_CHECKSIG, complete the script to be <sig> <pubKey> OP_CHECKSIG, and run it and afterwards check the address by looking at <pubKey>? Would that be safe? (Even if it is a hackish solution that only works for certain type of transactions): > Green addresses could be implemented as a second signature in the scriptSig. You'd have to hack your bitcoin client, but you could generate a transaction that had <greensig> <sig> <pubKey> ... as the input instead of <sig> <pubKey>. Interesting suggestion! So if I understand correctly, <greensig> would be the signature generated from signing the transaction with the key of a green address? Which would allow the rest of the transaction to be completely 'normal' and not require it to use specific inputs as such? Sounds good - I guess I never thought in this direction, as I always assumed doing anything 'non-standard' with the scripting language would create a number of knock-on problems. But you are saying, that this would still be considered standard? I guess I have to study this part of the source code more. Well, I guess I'm torn a little bit between two options: 1) Get something working reasonable fast to detect current green address style transactions. It's fine if it is a little bit of a hack, as long as it's safe, since I don't expect it to be merged with mainline anyway at this point. 2) Rethink how green transactions are created and verified and try to put something 'proper' together which has a chance of being merged at some point. For the moment I was going more with 1) because I got the impression, that green transactions are too controversial at this point to get them included in mainline. Criticism ranging from 'unnecessary, as 0-confirmation transactions are fairly safe today' to 'encourages too much centralization and therefore evil'. So how to people on this list feel about green transactions? Would people be interested in helping me with 2)? Regards, Jan ------------------------------------------------------------------------------ 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
