jav



Offline



Activity: 249

Merit: 250







Sr. MemberActivity: 249Merit: 250 Paper on marker addresses (aka green addresses) August 22, 2012, 03:19:01 PM #1 Paper



I have summarized the ideas around green addresses (I decided to call them marker addresses going forward) in a paper which got accepted and will be presented at a Bitcoin workshop & tutorial organized by Professor Clemens Cap of the University of Rostock. The workshop will take place on September 20th.



Paper:

Workshop website:



Marker/Green addresses are a proposal for a simple method of allowing a Bitcoin sender to identify herself to a recipient, to be used in cases where two parties have a trust relationship and want to recognize each other's transactions for special treatment (usually instant confirmation). They have been discussed before on this forum primarily in these two threads:



https://bitcointalk.org/index.php?topic=32818.0

https://bitcointalk.org/index.php?topic=48170



Implementation: Receiving



Since finishing the paper, I have been working some more on the implementation side of things (based on bitcoind git tag v0.6.3). For the receiving side (recognizing marker addresses on incoming transactions) I have implemented an "getorigins" RPC call:



https://github.com/javgh/bitcoin/tree/bw-getorigins

( diff to v0.6.3:



If you give getorigins a txid, it will (if the transaction has a suitable structure) display the addresses from where the coins came. For example for this transaction from Mt.Gox, where the green address feature was enabled, it returns this:



Code: ./bitcoind getorigins 162d25037687be593e1be27bf79583afa5141c7fcd168e068501f162d2016c9a



{

"confirmations" : 39,

"blockhash" : "00000000000003cb80e379d5fae8e19c2594d35881ec21ff54847d99e6894671",

"blockindex" : 110,

"txid" : "162d25037687be593e1be27bf79583afa5141c7fcd168e068501f162d2016c9a",

"time" : 1344887758,

"origins" : [

"1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q"

]

}



You would then check if a known green/marker address appears somewhere in the list. Here we see 1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q, which is the green address currently used by Mt.Gox. In the case of Mt.Gox the whole transaction is funded from that address, but the way the paper describes the technique it might just be one of the addresses appearing in the list.



Implementation: Sending



The sending part is still a little bit hacky. My code has a marker address hardcoded and expects that the local wallet has the necessary keys for it. It will then



Always try to add a single 0.01 BTC from that address to any outgoing transaction and an additional output sending it back. If this is not possible, the transaction creation will fail. It will resort to using marker coins with zero confirmations, if no others are available.

Mark those incoming transactions to the marker address as change, so that they do not appear in "listtransactions".

Prevent marker coins (coins at the marker address) from being used in any other way for a transaction, so that the marker address does not get depleted.

Add an extra option to "getbalance", which shows the actual available balance after subtracting marker coins.

https://github.com/javgh/bitcoin/tree/bw-markeraddress

(diff to v0.6.3:



The transaction



Future work



I am working on a new Bitcoin project which will also make use of marker addresses. I hope some nice demonstrations will come out of that, but that's still a couple of months off.



Comments, questions and other feedback is appreciated! :-)

I have summarized the ideas around green addresses (I decided to call them marker addresses going forward) in a paper which got accepted and will be presented at a Bitcoin workshop & tutorial organized by Professor Clemens Cap of the University of Rostock. The workshop will take place on September 20th.Paper: http://www.bitcoinmonitor.com/static/paper/marker-addresses.pdf Workshop website: http://bitcoin.uni-rostock.de/index.php?site=callforpapers_en Marker/Green addresses are a proposal for a simple method of allowing a Bitcoin sender to identify herself to a recipient, to be used in cases where two parties have a trust relationship and want to recognize each other's transactions for special treatment (usually instant confirmation). They have been discussed before on this forum primarily in these two threads:https://bitcointalk.org/index.php?topic=32818.0https://bitcointalk.org/index.php?topic=48170Since finishing the paper, I have been working some more on the implementation side of things (based on bitcoind git tag v0.6.3). For the receiving side (recognizing marker addresses on incoming transactions) I have implemented an "getorigins" RPC call:( diff to v0.6.3: https://github.com/javgh/bitcoin/compare/bw-master...bw-getorigins If you give getorigins a txid, it will (if the transaction has a suitable structure) display the addresses from where the coins came. For example for this transaction from Mt.Gox, where the green address feature was enabled, it returns this:You would then check if a known green/marker address appears somewhere in the list. Here we see 1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q, which is the green address currently used by Mt.Gox. In the case of Mt.Gox the whole transaction is funded from that address, but the way the paper describes the technique it might just be one of the addresses appearing in the list.The sending part is still a little bit hacky. My code has a marker address hardcoded and expects that the local wallet has the necessary keys for it. It will then(diff to v0.6.3: https://github.com/javgh/bitcoin/compare/bw-master...bw-markeraddress The transaction http://blockchain.info/tx-index/15610835/5fcc25b576547aafddc1fed22d27259478d6c000540cb458df44c629eb10bd0b?show_adv=true is an example for a marker transaction created in this way. In this case the marker address is 1MAbwuYp8CPChJ1ua25tnEKXkfXTVqEoyg.I am working on a new Bitcoin project which will also make use of marker addresses. I hope some nice demonstrations will come out of that, but that's still a couple of months off.Comments, questions and other feedback is appreciated! :-) Hive , a beautiful wallet with an app platform for Mac OS X Android and Mobile Web Translators wanted! iOS and OS X devs see BitcoinKit . Tweets @hivewallet . Donations appreciated at 1HLRg9C1GsfEVH555hgcjzDeas14jen2Cn

gmaxwell

Legendary





Offline



Activity: 3192

Merit: 4308









ModeratorLegendaryActivity: 3192Merit: 4308 Re: Paper on marker addresses (aka green addresses) August 22, 2012, 03:32:09 PM #2 Quote from: jav on August 22, 2012, 03:19:01 PM I am working on a new Bitcoin project which will also make use of marker addresses. I hope some nice demonstrations will come out of that, but that's still a couple of months off.

Comments, questions and other feedback is appreciated! :-)

Thats unfortunate, because they're really a bad idea.



There are multiple problems with marker addresses but foremost among them is that they're incompatible with Bitcoin's privacy model and their use harms the privacy of not only the people who use them but also people who transact with people who use them (and so on, transitively with decaying harm). They also encourage poor key management practices (e.g. constantly assigning funds to a long term online key which is potentially subject to theft), and an additional burden on the public network to convey store additional information that is only interesting to a single pair of parties.



We added the signmessage feature in order to have detached, private, identification authentication available. Rather than in-band marking a party can trivially sign a transaction ID with an address reserved for that purpose and then pass it over whatever mechanism they like (including appending the signature to the normal transaction ID they display). This avoids all of the concerns above related to marker addresses.

Thats unfortunate, because they're really a bad idea.There are multiple problems with marker addresses but foremost among them is that they're incompatible with Bitcoin's privacy model and their use harms the privacy of not only the people who use them but also people who transact with people who use them (and so on, transitively with decaying harm). They also encourage poor key management practices (e.g. constantly assigning funds to a long term online key which is potentially subject to theft), and an additional burden on the public network to convey store additional information that is only interesting to a single pair of parties.We added the signmessage feature in order to have detached, private, identification authentication available. Rather than in-band marking a party can trivially sign a transaction ID with an address reserved for that purpose and then pass it over whatever mechanism they like (including appending the signature to the normal transaction ID they display). This avoids all of the concerns above related to marker addresses.

Pieter Wuille





Offline



Activity: 1064

Merit: 1039







LegendaryActivity: 1064Merit: 1039 Re: Paper on marker addresses (aka green addresses) August 22, 2012, 04:09:25 PM #4



The root of the problem - in my opinion - is the fact that the only widely-supported way of doing a bitcoin transaction, is in fact already by using the block chain as a communication channel. Satoshi originally envisioned that transactions would be done using a pay-to-IP-address protocol, and not via pay-via-blockchain-to-public-key-hash (what we do now). In many ways, pay-to-IP is far superior, however: It sends the transaction directly to the one who needs it, instead of forcing him to scan the entire blockchain for things that look like a payment to him.

It moves the responsability for getting the transaction accepted to the only one who cares about that.

It allows adding comments, order id's, or whatever message you like to the transactions (including proof that it comes from a trusted party), completely private, and without bloating a very expensive distributed database (the block chain).

Over time, however, pay-to-IP had many shortcomings, and became obsolete, and eventually disabled.



I think it is time we introduce a new way for doing direct payments, with the advantages of pay-to-IP, but properly authenticated and secured. I don't think the solution is tagging the Bitcoin transaction itself (which only requires data necessary for the world to validate it) with data that decreases the privacy of the entire system.

What this does in essence, is using the block chain as a communication channel for private information. That may seem to be an easy solution right now, because of how the current Bitcoin infrastructure operates, but it has so many disadvantages (like gmaxwell already described).The root of the problem - in my opinion - is the fact that the only widely-supported way of doing a bitcoin transaction,in fact already by using the block chain as a communication channel. Satoshi originally envisioned that transactions would be done using a pay-to-IP-address protocol, and not via pay-via-blockchain-to-public-key-hash (what we do now). In many ways, pay-to-IP is far superior, however:Over time, however, pay-to-IP had many shortcomings, and became obsolete, and eventually disabled.I think it is time we introduce a new way for doing direct payments, with the advantages of pay-to-IP, but properly authenticated and secured. I don't think the solution is tagging the Bitcoin transaction itself (which only requires data necessary for the world to validate it) with data that decreases the privacy of the entire system. I do Bitcoin stuff.

gmaxwell

Legendary





Offline



Activity: 3192

Merit: 4308









ModeratorLegendaryActivity: 3192Merit: 4308 Re: Paper on marker addresses (aka green addresses) August 22, 2012, 04:23:01 PM

Last edit: August 22, 2012, 06:08:57 PM by gmaxwell #5 Quote from: davout on August 22, 2012, 03:47:17 PM There is no such thing as a "bitcoin privacy model".



There absolutely is,



Quote The green address system is opt-in.



Only partially. The sender can opt-in. The receiver gets it if sender chose, if they like it or not. Further downstream users who's identity is now more disclosed by association with a named entity in the block-chain don't really get a say at all. The hundreds of thousands of other uninterested nodes will waste cpu cycles validating these signatures (and the pointless transactions required to create the inputs) and storage recording them, even those these transactions do not serve to further their interests in the way that general blockchain validation does. They could, of course, filter out the ones that they're aware of, but unless they all do it they'll be forced to validate them when they are mined or risk their security.



There are many sources of cost here and most of them are externalized.



Quote Quote from: gmaxwell on August 22, 2012, 03:32:09 PM They also encourage poor key management practices (e.g. constantly assigning funds to a long term online key which is potentially subject to theft),

That somewhat goes with the "instant transfer" feature, I don't think you can really have this without leaving some key online at some point. You could still mitigate that risk by using a multiple signature address as marker address.

That somewhat goes with the "instant transfer" feature, I don't think you can really have this without leaving some key online at some point. You could still mitigate that risk by using a multiple signature address as marker address.

It doesn't. A transaction requires only the keys being online that sign for the particular input coins. Prudent key management would have those keys used only once. A marker address is a long term key. In-band marker address usage requires constantly assigning funds do a long term key. It's a bad practice and increases the exposure to theft, if only marginally.



Quote "conveying information that is only interesting to a single pair of parties" is pretty much what Bitcoin already does. At the end of the day it's the market that will decide what's a fair price for this additional bit of information. It seems logical that instant transactions between green-address aware parties might cost a little more.



Bitcoin has gone to rather extraordinary lengths to avoid including any more data than strictly necessary in the globally and eternally visible flooded blockchain. The only data included is the minimum required to have the system be fully decentralized, secure, and inflation proof. This information is in the interest of all bitcoin users: we want to protect you from double spends because we want to prevent inflation in order to make Bitcoin useful. If it were believed to be viable to include a memo field in transactions there would be one; it isn't like the usefulness of them is a surprise (the old IP transactions had a memo field, in fact, but they never showed up in the public network.)



There is no mechanism available to directly compensate most of the parties that undertake the costs created by a third party's use of in-band marker addresses.



Quote from: gmaxwell on August 22, 2012, 03:32:09 PM You just need blockexplorer or a similar tool to validate a green address transfer which is much simpler than validating a detached signature.



There is no reason that other schemes can't be made just as easy or even easier, since they have a chance of being integrated. Validating a detached signature using blockexplorer could be as simple as following a link. E.g. With a simple bit of JS,



Of course, as Pieter points out payment protocols are even more powerful. There are a lot of superior options.



My concern is that things like inband-marker addresses discourage the implementation of better solutions which have fewer compromises simply because it has a lower startup cost. As a community we need to resist that kind of lazyness if we're to keep our system healthy.



Edit: With some code from Joric, I setup exactly There absolutely is, http://bitcoin.org/bitcoin.pdf Section 10.Only partially. The sender can opt-in. The receiver gets it if sender chose, if they like it or not. Further downstream users who's identity is now more disclosed by association with a named entity in the block-chain don't really get a say at all. The hundreds of thousands of other uninterested nodes will waste cpu cycles validating these signatures (and the pointless transactions required to create the inputs) and storage recording them, even those these transactions do not serve to further their interests in the way that general blockchain validation does. They could, of course, filter out the ones that they're aware of, but unless they all do it they'll be forced to validate them when they are mined or risk their security.There are many sources of cost here and most of them are externalized.It doesn't. A transaction requires only the keys being online that sign for the particular input coins. Prudent key management would have those keys used only once. A marker address is a long term key. In-band marker address usage requires constantly assigning funds do a long term key. It's a bad practice and increases the exposure to theft, if only marginally.Bitcoin has gone to rather extraordinary lengths to avoid including any more data than strictly necessary in the globally and eternally visible flooded blockchain. The only data included is the minimum required to have the system be fully decentralized, secure, and inflation proof. This information is in the interest of all bitcoin users: we want to protect you from double spends because we want to prevent inflation in order to make Bitcoin useful. If it were believed to be viable to include a memo field in transactions there would be one; it isn't like the usefulness of them is a surprise (the old IP transactions had a memo field, in fact, but they never showed up in the public network.)There is no mechanism available to directly compensate most of the parties that undertake the costs created by a third party's use of in-band marker addresses.There is no reason that other schemes can't be made just as easy or even easier, since they have a chance of being integrated. Validating a detached signature using blockexplorer could be as simple as following a link. E.g. With a simple bit of JS, http://blockexplorer.com/tx/eb620fe4cdc24afbd2ded229577c64fbb099a39e80bcc15750b84c04b7878d90#G7mlJ2Db1W68LQPkqNt0UAyEE9xNI4KVMxy/GSwI/TU8GH2rUzs7jKFr9yq6M43zsKUHlqIF9HQ1pypvWpuUg8E= could display "This transaction is certified against reversal by 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB"Of course, as Pieter points out payment protocols are even more powerful. There are a lot of superior options.My concern is that things like inband-marker addresses discourage the implementation of better solutions which have fewer compromises simply because it has a lower startup cost. As a community we need to resist that kind of lazyness if we're to keep our system healthy.Edit: With some code from Joric, I setup exactly the validation I described above . The signature checking is all client side, so the normal operaiton of the site doesn't even cause them to learn the relevant marker addresses being checked unless they go out of their way to inject monitoring code.

pc



Offline



Activity: 253

Merit: 250







Sr. MemberActivity: 253Merit: 250 Re: Paper on marker addresses (aka green addresses) August 23, 2012, 01:35:22 PM #8 If miners are going to charge for it anyway, then one might as well use transactions of 0 BTC instead of 0.01 BTC for the marker address input/output. The only reason to have it be 0.01 is that it avoids the too-small-transaction fee on a transaction that would otherwise be free.