Re: [Bitcoin-development] Determine input addresses of a transaction
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
Re: [Bitcoin-development] Determine input addresses of a transaction
On Tue, 2011-10-25 at 11:45 +0200, Jan Vornberger wrote: 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)? One possibility would be to create a peer sourced green address implementation. That is, each user could, individually decide to trust certain addresses as green and optionally, publish this trust. Basing things on the published trust, you could dynamically, as opposed to static hierarchies, evaluate the trustworthiness of each green address you haven't personally decided to trust. This would be somewhat involved implementation, though, as it would require heavy statistical calculations. - Joel -- 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] Determine input addresses of a transaction
Interesting suggestion! So if I understand correctly, greensig would be the signature generated from signing the transaction with the key of a green address? Sure. Or just a key. It wouldn't have to be an actual key used in the block chain. 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. It won't break the IsStandard checks, if that's what you mean. You can put any data you like into a scriptSig. In practice only data is useful, there's no purpose in having an actual script there (or at least, I wasn't able to find one yet). 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. You could easily change the bitcoin code to detect such transactions - just look for scriptSigs that have 3 items instead of two, where the 3rd item is the right size to be a signature. Criticism ranging from 'unnecessary, as 0-confirmation transactions are fairly safe today' to 'encourages too much centralization and therefore evil' Heh, if that's a reference to my feedback, I definitely wouldn't describe such a feature as evil, that's rather strong :-) -- 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
