Topic: Using bitcoind to determine sending address to check for green address (Read 2006 times)

Pieter,

Pull 841 was perfect.  I am now able to validate green address transactions locally.

Thanks,
Dan

Try to find gavin's monitoring patch and modify it to push each received TX to your software. This way you'll be able to accept TXes from green addresses with 0 confirmations.

Deepbit happily uses green addresses and if you have any questions you can PM or e-mail me.

Nice. Seems to add much of the stuff I need :-)

You may be interested in pull requests 841 and/or 886, which add such functionality to the reference client.

I must admit that I agree with gmaxwell here on the topic of green addresses: they use the block chain as a communication channel for what is essentially private information. Nonetheless, seeing block's and transaction's full contents is sometimes useful.

Have a look at the bitcoin fork I made for www.bitcoinmonitor.net.

Among some other stuff the rpc command "getBlock" is extended to include basically the full block information, including all transactions with inputs and outputs that are contained in a block.
Also there is a new command "getAnyTransaction" which can be used to get information on any transaction known, not only to transactions which involve your own wallet. Also here all inpoints and outpoints are included.

=> https://github.com/TripleSpeeder/bitcoin

HTH.

Although green addresses could be debated, I am still looking for a way to identify them locally.

Are there any good solutions right now that allow someone to determine the inputs and outputs of a transaction (locally, without querying a web service)?  This would have to include unconfirmed transactions as well (otherwise abe would be a good option). 

Any ideas are appreciated.

I have a simple protocol here for private messages associated with transactions which can only be read by the reviver. This would allow inband broadcast green addresses without compromising privacy or bloating the blockchain:

Say we have a TXN(Me->You) with a TXID.  I want to tell you that it was really RealME who created this transaction, even though no one knows who Me is, and I want to do this in a way you can prove to others that RealMe claims to be Me should I screw you... but we don't want anyone else to know otherwise.

So I first send TXN(Me->You) on the network.

I then form a message to be sent secretly to you  Message={TXID,SIGN(RealMe,TXID)}

I then compute Ek = ECDH(Me_private,You_public) and then compute Em = Enc(Ek,Message).

Then I sign Em,  Sig_EM = SIGN(Me,TXID||Em) and finally I broadcast {TXID,Em,Sig_EM}.

Relaying nodes are able to associate the message to a particular recent transaction and only allow one (or a small number) of messages to prevent DOS.  But other than telling that the sender of TXN(Me->You) send a message they learn nothing more.

The recipient of the transaction would see they received a message. They could repeat the procedure, decode the message, and find the signature in it proving that RealMe claims responsibility for the transaction.   Should I cheat them by reneging on the transaction, they could publish the signature to prove my untrustworthyness.

The problem here is that the addresses we send funds to don't include a public key... only the hash of the public key. So I probably don't know You_public to perform the ECDH.   This could be resolved by making an address type with an extra 256 bit compressed public key tacked on the end.  This key would only be used to receive private messages associated with the address.  (This would also have the benefits of working with P2SH transactions, even complicated multisig ones so long as you don't mind that there is a single address which can be used to decode messages).

Such a system would enable some unfortunate additional parasitic applications of the Bitcoin network... but better to have them only ephemerally sending a limited amount of traffic rather than imposing on the blockchain for all time. By rate limiting these messages based on transactions they shouldn't make the situation any worse.

I'm not generally in favor of this at this time.  "Green addresses" add irrelevant bloat to the block chain (no one but the recipient cares about that data, certainly not people 10 years from now) and compromise the privacy of Bitcoin users— even people who aren't directly the users of green addresses.  They also encourage poor key management practices (e.g. keep all your funds on a single green address) or even more chain bloat (by doing two step transactions).

I also understand from talking to Magicaltux that green addresses have not been much of a success.

We added the signmessage functionality so that people could use a well known public key (your green address if you will) to sign any data they want, including transaction IDs, without putting anything in the blockchain or publishing it.    For example, when you made a withdraw from a trusted bank, the bank could use its well known key to signmessage the relevant transaction ID.  It could then either send this signature directly to the recipient if you provided a payment URL,  or provide it to the user as a "confirmation value" which they could carry over to the other side.

Unfortunately MTGOX did not implement the former because they don't want their customers telling them that they're sending funds to $QUESTIONABLE_PLACE, and didn't implement the latter because it's not fully automatic.

I am considering adding support to my service for a couple of green addresses.

Is there a way to use the standard bitcoind to determine the source of incoming transactions?  Or am I required to use a web service such as blockchain.info or roll my own client?

A patch to the standard bitcoin client would be great.  

Thoughts?

Dan