I see. That is undeniably more secure and "bitcoin-y" than my suggestion. It's also really a lot more work, especially in that it requires extra linkages between codebases that in my mind are largely separate. I'm just one voice, but I persist in believing that the 'lighter' solution, especially for something that may not be a particularly big problem in the bitcoin world is good -- it carries much less technical implementation debt going forward, and has a lower risk of sort of seizing up development with additional necessary code to worry about for those implementing to-spec clients. If that lighter solution turns out to be gameable, or has problems that require the full force of the bitcoin network and concepts, that would be the time to implement the improved version. That's just my approach, however. I worry that building in any additional requirements to the protocol or codebase adds significant cost to the network as a whole over the next 10 years. Peter On Tue, May 29, 2012 at 11:39 AM, Luke-Jr wrote: > On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote: > > I suppose I mean that I don't understand how to reverse that into a URL > > when one is presented only with a block, or perhaps a coinbase in a > > transaction. > > A new message can be added to the p2p relay network, similar to tx and > alert > broadcasts, that allow miners to publish/update their policy URI signed by > the > key in question. Counter-DDoS rules could decline to relay or store URIs > for > keys that haven't been published in - or achieved statistical significance > in > - the last N blocks. > -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 Skype: vessenes Google+