📅 Original date posted:2012-04-03
📝 Original message:Just to clarify, I'm not proposing anything to the protocol itself.
Simply that some applications might benefit from users being to sign
messages with existing Bitcoin identities, and what can we do to
accommodate that (out of band)? It's not a high priority, but I think
it's potentially useful, and most codebases already have everything they
need in place to implement it.
On 04/03/2012 04:04 PM, Peter Vessenes wrote:
> I don't think it's minimally invasive to layer PGP's web of trust on
> top of Bitcoin, in fact, the opposite.
>
> From a certain angle, bitcoin exists as a sort of answer / alternate
> solution to the web of trust. Digital cash with an existing web of
> trust in place was a working concept in the mid-1990s, courtesy of
> David Chaum, I believe.
>
> I totally agree on the kitchen sink concern; I would personally like
> to see something like a one-year required discussion period on all
> non-security changes proposed to the blockchain protocol. We know
> almost nothing about how bitcoin will be used over the next 20 years;
> I believe it's a mistake to bulk up the protocol too rapidly right now.
>
> There's a famous phrase from the founder of Lotus about Lotus'
> engineering process: "add lightness." The equivalent for protocol
> design might be "add simplicity." I'd like to see us adding simplicity
> for now, getting a core set of tests together for alternate
> implementations like libbitcoin, and thinking hard about the dangers
> of cruft over a 10+ year period when it comes to a technology which
> will necessarily include a complete history of every crufty decision
> embodied in transaction histories.
>
> Peter
>
>
> On Tue, Apr 3, 2012 at 1:42 PM, Wladimir <laanwj at gmail.com
> <mailto:laanwj at gmail.com>> wrote:
>
>
> On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <luke at dashjr.org
> <mailto:luke at dashjr.org>> wrote:
>
> On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
> > We should avoid reinventing the wheel, if we can. I think we
> should
> > extend existing standards whenever possible.
>
> I wonder if it's possible to make sigs compatible with PGP/EC ?
>
>
> Or we could take a step back, further into "don't reinvent the
> wheel" territory. Why not simply make use of PGP(/EC) to sign and
> verify messages? It has many advantages, like an already existing
> web-of-trust and keyserver infrastructure.
>
> I still feel like this is sign message stuff is dragging the
> kitchen sink into Bitcoin. It's fine for logging into a website,
> what you use it for, but anything that approaches signing email
> (such as S/MIME implementations and handling different character
> encodings) is going too far IMO.
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> --
>
> Peter J. Vessenes
> CEO, CoinLab
> M: 206.595.9839
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120403/c948c48e/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 10:02:48
in reply to nevent1q…wfr9
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hPublished at
2023-06-07 10:02:48Event JSON
{
"id": "cad1e47af96601f574f1d2effdfe702cef23bdcfcaf1ad75cd4facfb1f9c5070",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686132168,
"kind": 1,
"tags": [
[
"e",
"5bb4d423408bf0b009521e7b4ef6cfba42eb5b63ea5422c4d57e282127cd740e",
"",
"root"
],
[
"e",
"372e6347c1dc404c1fb58edc63e7538238ffbcaaec1c6f31f90f631bd071758c",
"",
"reply"
],
[
"p",
"c8914ab5f1efb93771e9c5b7fe20dcff2c343f46f4846ae6689a0c9478b04e01"
]
],
"content": "📅 Original date posted:2012-04-03\n📝 Original message:Just to clarify, I'm not proposing anything to the protocol itself. \nSimply that some applications might benefit from users being to sign \nmessages with existing Bitcoin identities, and what can we do to \naccommodate that (out of band)? It's not a high priority, but I think \nit's potentially useful, and most codebases already have everything they \nneed in place to implement it.\n\n\nOn 04/03/2012 04:04 PM, Peter Vessenes wrote:\n\u003e I don't think it's minimally invasive to layer PGP's web of trust on \n\u003e top of Bitcoin, in fact, the opposite.\n\u003e\n\u003e From a certain angle, bitcoin exists as a sort of answer / alternate \n\u003e solution to the web of trust. Digital cash with an existing web of \n\u003e trust in place was a working concept in the mid-1990s, courtesy of \n\u003e David Chaum, I believe.\n\u003e\n\u003e I totally agree on the kitchen sink concern; I would personally like \n\u003e to see something like a one-year required discussion period on all \n\u003e non-security changes proposed to the blockchain protocol. We know \n\u003e almost nothing about how bitcoin will be used over the next 20 years; \n\u003e I believe it's a mistake to bulk up the protocol too rapidly right now.\n\u003e\n\u003e There's a famous phrase from the founder of Lotus about Lotus' \n\u003e engineering process: \"add lightness.\" The equivalent for protocol \n\u003e design might be \"add simplicity.\" I'd like to see us adding simplicity \n\u003e for now, getting a core set of tests together for alternate \n\u003e implementations like libbitcoin, and thinking hard about the dangers \n\u003e of cruft over a 10+ year period when it comes to a technology which \n\u003e will necessarily include a complete history of every crufty decision \n\u003e embodied in transaction histories.\n\u003e\n\u003e Peter\n\u003e\n\u003e\n\u003e On Tue, Apr 3, 2012 at 1:42 PM, Wladimir \u003claanwj at gmail.com \n\u003e \u003cmailto:laanwj at gmail.com\u003e\u003e wrote:\n\u003e\n\u003e\n\u003e On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr \u003cluke at dashjr.org\n\u003e \u003cmailto:luke at dashjr.org\u003e\u003e wrote:\n\u003e\n\u003e On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:\n\u003e \u003e We should avoid reinventing the wheel, if we can. I think we\n\u003e should\n\u003e \u003e extend existing standards whenever possible.\n\u003e\n\u003e I wonder if it's possible to make sigs compatible with PGP/EC ?\n\u003e\n\u003e\n\u003e Or we could take a step back, further into \"don't reinvent the\n\u003e wheel\" territory. Why not simply make use of PGP(/EC) to sign and\n\u003e verify messages? It has many advantages, like an already existing\n\u003e web-of-trust and keyserver infrastructure.\n\u003e\n\u003e I still feel like this is sign message stuff is dragging the\n\u003e kitchen sink into Bitcoin. It's fine for logging into a website,\n\u003e what you use it for, but anything that approaches signing email\n\u003e (such as S/MIME implementations and handling different character\n\u003e encodings) is going too far IMO.\n\u003e\n\u003e Wladimir\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Better than sec? Nothing is better than sec when it comes to\n\u003e monitoring Big Data applications. Try Boundary one-second\n\u003e resolution app monitoring today. Free.\n\u003e http://p.sf.net/sfu/Boundary-dev2dev\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003cmailto:Bitcoin-development at lists.sourceforge.net\u003e\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e -- \n\u003e\n\u003e Peter J. Vessenes\n\u003e CEO, CoinLab\n\u003e M: 206.595.9839\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Better than sec? Nothing is better than sec when it comes to\n\u003e monitoring Big Data applications. Try Boundary one-second\n\u003e resolution app monitoring today. Free.\n\u003e http://p.sf.net/sfu/Boundary-dev2dev\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120403/c948c48e/attachment.html\u003e",
"sig": "555cd6b4fa9f1ab3a2b3d1e85462c0ee4b2d743f9c0a698114e237fe5d353de6f98701b0d94ba873197b7316e3f0340da808d837dcae166c2b902ef757f15197"
}