Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1R79iG-0002os-LQ for bitcoin-development@lists.sourceforge.net; Fri, 23 Sep 2011 17:39:00 +0000 X-ACL-Warn: Received: from serv.jerviss.org ([12.47.47.47] helo=inana.jerviss.org) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1R79iF-0005m7-No for bitcoin-development@lists.sourceforge.net; Fri, 23 Sep 2011 17:39:00 +0000 Received: from [156.99.25.142] ([156.99.25.142]) (username: kjj authenticated by PLAIN symmetric_key_bits=0) by inana.jerviss.org (8.13.6/8.12.11) with ESMTP id p8NHcmi1020896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 12:38:52 -0500 Message-ID: <4E7CC428.6020500@jerviss.org> Date: Fri, 23 Sep 2011 12:38:48 -0500 From: kjj User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 SeaMonkey/2.3.3 MIME-Version: 1.0 To: Pieter Wuille References: <20110923162102.GA13532@ulyssis.org> In-Reply-To: <20110923162102.GA13532@ulyssis.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (inana.jerviss.org: 156.99.25.142 is authenticated by a trusted mechanism) X-Spam-Score: -1.9 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1R79iF-0005m7-No Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Beyond IP transactions: towards a bitcoin payment protocol X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 17:39:00 -0000 Pieter Wuille wrote: > Hello everyone, > > here is an idea i've bean writing up: https://gist.github.com/1237788 > > I hope it can start some discussion about moving away from static bitcoin addresses > as descriptions for transactions. I suppose it's a candidate for a BIP/BEPS/BFC/..., > but as things don't seem to have been decided completely about those, I put it in a > Gist. > > Please, comment. > This may just be me, but this really looks like an incredibly convoluted way to solve a bunch of problems that aren't really problems. The central issue that I see, is that you assume that there is no out of band channel, as if people were just sending transactions to addresses that came to them in a dream. I think that this assumption is only true when it doesn't matter. For example, I have a donation link in my sig on the forums. I don't care much who sends to it, or why, and I certainly don't need annotations or a refund address. The rest of the time, payments are sent to addresses that already have sufficient context. Only one of the advantages listed is actually an advantage. That is that payments to stale addresses can be stopped. This isn't much of an advantage though, as someone blindly sending payments (donations, really) to addresses found on backup tapes and web archives without verifying that they are still current kinda deserve what they get. So it really only stops payments to services that go defunct the same day (more or less). In the end, I just don't see the value in giving a URL so that I can go ask a server for information that could just as easily have been encoded in the URL directly. Then again, I'm cynical, and didn't sleep very well last night. Maybe the next person will think better of it.