📅 Original date posted:2012-05-29
📝 Original message: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 <luke at dashjr.org> 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+ <https://plus.google.com/112885659993091300749>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120529/dc488769/attachment.html>;
Peter Vessenes [ARCHIVE] /
npub1ez…6r8pt
2023-06-07 10:10:47
in reply to nevent1q…9e6m
Author Public Key
npub1ezg54d03a7unwu0fckmlugxulukrg06x7jzx4engngxfg79sfcqsn6r8ptSeen on
wss://relay.nostr.bandPublished at
2023-06-07 10:10:47Event JSON
{
"id": "a58b025222dc410ba4241efe6fd45c2bd935a3e2b11af63172fd7d00f30d0e0e",
"pubkey": "c8914ab5f1efb93771e9c5b7fe20dcff2c343f46f4846ae6689a0c9478b04e01",
"created_at": 1686132647,
"kind": 1,
"tags": [
[
"e",
"bea123cfa1dde96d98089cdcf953f77564e34363cd7b11c4a3504634664d4aa2",
"",
"root"
],
[
"e",
"f366e121431d41853961934b6c6882fab540229b45997a47c3e0f8dd8c595090",
"",
"reply"
],
[
"p",
"6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1"
]
],
"content": "📅 Original date posted:2012-05-29\n📝 Original message:I see. That is undeniably more secure and \"bitcoin-y\" than my suggestion.\n\nIt's also really a lot more work, especially in that it requires extra\nlinkages between codebases that in my mind are largely separate.\n\nI'm just one voice, but I persist in believing that the 'lighter' solution,\nespecially for something that may not be a particularly big problem in the\nbitcoin world is good -- it carries much less technical implementation debt\ngoing forward, and has a lower risk of sort of seizing up development with\nadditional necessary code to worry about for those implementing to-spec\nclients.\n\nIf that lighter solution turns out to be gameable, or has problems that\nrequire the full force of the bitcoin network and concepts, that would be\nthe time to implement the improved version. That's just my approach,\nhowever. I worry that building in any additional requirements to the\nprotocol or codebase adds significant cost to the network as a whole over\nthe next 10 years.\n\nPeter\n\nOn Tue, May 29, 2012 at 11:39 AM, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote:\n\u003e \u003e I suppose I mean that I don't understand how to reverse that into a URL\n\u003e \u003e when one is presented only with a block, or perhaps a coinbase in a\n\u003e \u003e transaction.\n\u003e\n\u003e A new message can be added to the p2p relay network, similar to tx and\n\u003e alert\n\u003e broadcasts, that allow miners to publish/update their policy URI signed by\n\u003e the\n\u003e key in question. Counter-DDoS rules could decline to relay or store URIs\n\u003e for\n\u003e keys that haven't been published in - or achieved statistical significance\n\u003e in\n\u003e - the last N blocks.\n\u003e\n\n\n\n-- \nPeter J. Vessenes\nCEO, CoinLab\nM: 206.595.9839\nSkype: vessenes\nGoogle+ \u003chttps://plus.google.com/112885659993091300749\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120529/dc488769/attachment.html\u003e",
"sig": "d0590d57ed73255954b13ccab086ed9bbfab6f38bc8dbe705887cfe25c737dfa02326a8c9581d374edd858b415934b27448d3f7fde025dd280868af41d0446c2"
}