📅 Original date posted:2014-04-01
📝 Original message:Hi Daryl
I think the two issues with this are
1) pay to addresses are not fixed - ie you can have a different address for each transaction (which is why BIP70 is necessary to allow per transaction addresses via https.)
2) unless you are already aware of the public key of the signature, you do not know if the signature is made by the person you think it is supposed to be from. See recent concern over fake key for Gavin Andresen. Ie a signature can always be verified with a valid public key, the question is was it the real person's key. That is what WoT tried to resolve with so-called "signing parties", nowadays keys posted to a public forum by a known user, but it's not a standard and not ideal.
Regards
Chris D'Costa
Sent from my iPhone
> On 1 Apr 2014, at 20:16, Daryl Banttari <dbanttari at gmail.com> wrote:
>
> I posted some code on Reddit a while back around adding a simple x509 digital signature to a Bitcoin address URL, since you could gain the benefit of an x.509 authenticated Bitcoin address without having to do a full BIP70 implementation. It's not WoT, but x509, for all its flaws, works very well in the real world almost all of the time.
>
> For added authentication, one could always wrap the URL with a PGP signature.
>
> After lurking on this list for a while, I assumed there's some reason this hasn't already been implemented, likely based in the general disgust around x509.
>
> Anyway, here's my idea (complete with working Java source):
>
> http://www.reddit.com/r/BitcoinSerious/comments/1sebj0/proposal_bitcoin_invoice_signatures/
>
> FWIW.
>
> --Daryl
>
>
>
>> On Tue, Apr 1, 2014 at 7:20 AM, Chris D'Costa <chris.dcosta at meek.io> wrote:
>> The code will be available as soon as we are ready, and apologies again for it not being a more meaningful conversation - I did say I hesitated about posting it ;)
>>
>> I think it is fair to say that we have not assumed anything about other technologies, without asking if they can answer all (not just some) of the questions I raised. I have yet to be convinced that anything existing meets those requirements, namecoin included, hence why we are looking at creating an alternative (non-coin by the way) but this alternative has some of the important properties that the distributed ledger provides.
>>
>> To answer the question about expiry, we're looking at something we'll call proof-of-life for the device keys. In a nutshell on of the pieces of information stored with the device public key will be a last heard from date - a date which is sent only by the device from time to time. Records that are expired are devices that have not been heard from for a given period (to be decided). As the device keys are not related to the Bitcoin keys it will be safe to expire a device key by default. An expired device would require reinitialisation, which would make a new device key set, a new proof of life date and then the Bitcoin keys (BIP32) can be restored.
>>
>>
>>
>> Regards
>>
>> Chris D'Costa
>>
>> Sent from my iPhone
>>
>> > On 1 Apr 2014, at 13:32, Jeff Garzik <jgarzik at bitpay.com> wrote:
>> >
>> > Re-reading this, even with the most recent message, is still isn't
>> > clear _precisely_ how your technology works, or why it is better than
>> > namecoin. User profiles (and distributed ledgers) need to reflect the
>> > latest updates, and a stream of updates of over time is precisely what
>> > bitcoin technology secures.
>> >
>> > Keys expire or are compromised, and the public ledger needs to reflect
>> > that. There is a lot of computer science involved in making sure the
>> > public ledger you see is not an outdated view. A log-like stream of
>> > changes is not the only way to do things, but other methods need less
>> > hand-wavy details (show the code) before they are well recognized as
>> > useful.
>> >
>> >
>> >
>> >> On Mon, Mar 31, 2014 at 7:14 AM, Chris D'Costa <chris.dcosta at meek.io> wrote:
>> >> Security of transmission of person-to-person pay-to addresses is one of the use cases that we are addressing on our hardware wallet.
>> >>
>> >> I have yet to finish the paper but in a nutshell it uses a decentralised ledger of, what we refer to as, "device keys".
>> >>
>> >> These keys are not related in any way to the Bitcoin keys, (which is why I'm hesitating about discussing it here) neither do they even attempt to identify the human owner if the device. But they do have a specific use case and that is to provide "advanced knowledge" of a publickey that can be used for encrypting a message to an intended recipient, without the requirement for a third-party CA, and more importantly without prior dialogue. We think it is this that would allow you to communicate a pay-to address to someone without seeing them in a secure way.
>> >>
>> >> As I understand it the BlockChain uses "time" bought through proof of work to establish a version of the truth, we are using time in the reverse sense : advanced knowledge of all pubkeys. Indeed all devices could easily check their own record to identify problems on the ledger.
>> >>
>> >> There is of course more to this, but I like to refer to the "distributed ledger of device keys" as the "Web-of-trust re-imagined" although that isn't strictly true.
>> >>
>> >> Ok there you have it. The cat is out of the bag, feel free to give feedback, I have to finish the paper, apologies if it is not a topic for this list.
>> >>
>> >> Regards
>> >>
>> >> Chris D'Costa
>> >>
>> >>
>> >>> On 31 Mar 2014, at 12:21, vv01f <vv01f at riseup.net> wrote:
>> >>>
>> >>> Some users on bitcointalk[0] would like to have their vanity addresses
>> >>> available for others easily to find and verify the ownership over a kind
>> >>> of WoT. Right now they sign their own addresses and quote them in the
>> >>> forums.
>> >>> As I pointed out there already the centralized storage in the forums is
>> >>> not secury anyhow and signed messages could be swapped easily with the
>> >>> next hack of the forums.
>> >>>
>> >>> Is that use case taken care of in any plans already?
>> >>>
>> >>> I thought about abusing pgp keyservers but that would suit for single
>> >>> vanity addresses only.
>> >>> It seems webfinger could be part of a solution where servers of a
>> >>> business can tell and proof you if a specific address is owned by them.
>> >>>
>> >>> [0] https://bitcointalk.org/index.php?topic=502538
>> >>> [1] https://bitcointalk.org/index.php?topic=505095
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> _______________________________________________
>> >>> Bitcoin-development mailing list
>> >>> Bitcoin-development at lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >>
>> >> ------------------------------------------------------------------------------
>> >> _______________________________________________
>> >> Bitcoin-development mailing list
>> >> Bitcoin-development at lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>> >
>> >
>> > --
>> > Jeff Garzik
>> > Bitcoin core developer and open source evangelist
>> > BitPay, Inc. https://bitpay.com/
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20140402/eb17bb32/attachment.html>;
Chris D'Costa [ARCHIVE] /
npub1qv…x33a6
2023-06-07 15:16:51
in reply to nevent1q…hguv
Author Public Key
npub1qvgc8w7mhjaspd7y2z9xuywch4xdll2rm6vy598rnmw0cuvezqnqfx33a6Published at
2023-06-07 15:16:51Event JSON
{
"id": "e33182aa922003ad59291dd2b02f5944b84cced8f7a4744818e13fc6ceeb184b",
"pubkey": "031183bbdbbcbb00b7c4508a6e11d8bd4cdffd43de984a14e39edcfc71991026",
"created_at": 1686151011,
"kind": 1,
"tags": [
[
"e",
"117fee8aae72bd39712f607951dfeb16a013cd2982264ffa6870b0ff16f9d829",
"",
"root"
],
[
"e",
"4a04796d1e9e73aec159fd489500d7d9f96b0681ed856807e7ee4540b83cd4c2",
"",
"reply"
],
[
"p",
"b93537b33ff313b72e93e65630def47b9d96091e0bf515d879ec2723c9f19fc2"
]
],
"content": "📅 Original date posted:2014-04-01\n📝 Original message:Hi Daryl\n\nI think the two issues with this are\n1) pay to addresses are not fixed - ie you can have a different address for each transaction (which is why BIP70 is necessary to allow per transaction addresses via https.)\n2) unless you are already aware of the public key of the signature, you do not know if the signature is made by the person you think it is supposed to be from. See recent concern over fake key for Gavin Andresen. Ie a signature can always be verified with a valid public key, the question is was it the real person's key. That is what WoT tried to resolve with so-called \"signing parties\", nowadays keys posted to a public forum by a known user, but it's not a standard and not ideal.\n\n\n\nRegards\n\nChris D'Costa\n\n\nSent from my iPhone\n\n\u003e On 1 Apr 2014, at 20:16, Daryl Banttari \u003cdbanttari at gmail.com\u003e wrote:\n\u003e \n\u003e I posted some code on Reddit a while back around adding a simple x509 digital signature to a Bitcoin address URL, since you could gain the benefit of an x.509 authenticated Bitcoin address without having to do a full BIP70 implementation. It's not WoT, but x509, for all its flaws, works very well in the real world almost all of the time.\n\u003e \n\u003e For added authentication, one could always wrap the URL with a PGP signature.\n\u003e \n\u003e After lurking on this list for a while, I assumed there's some reason this hasn't already been implemented, likely based in the general disgust around x509.\n\u003e \n\u003e Anyway, here's my idea (complete with working Java source):\n\u003e \n\u003e http://www.reddit.com/r/BitcoinSerious/comments/1sebj0/proposal_bitcoin_invoice_signatures/\n\u003e \n\u003e FWIW.\n\u003e \n\u003e --Daryl\n\u003e \n\u003e \n\u003e \n\u003e\u003e On Tue, Apr 1, 2014 at 7:20 AM, Chris D'Costa \u003cchris.dcosta at meek.io\u003e wrote:\n\u003e\u003e The code will be available as soon as we are ready, and apologies again for it not being a more meaningful conversation - I did say I hesitated about posting it ;)\n\u003e\u003e \n\u003e\u003e I think it is fair to say that we have not assumed anything about other technologies, without asking if they can answer all (not just some) of the questions I raised. I have yet to be convinced that anything existing meets those requirements, namecoin included, hence why we are looking at creating an alternative (non-coin by the way) but this alternative has some of the important properties that the distributed ledger provides.\n\u003e\u003e \n\u003e\u003e To answer the question about expiry, we're looking at something we'll call proof-of-life for the device keys. In a nutshell on of the pieces of information stored with the device public key will be a last heard from date - a date which is sent only by the device from time to time. Records that are expired are devices that have not been heard from for a given period (to be decided). As the device keys are not related to the Bitcoin keys it will be safe to expire a device key by default. An expired device would require reinitialisation, which would make a new device key set, a new proof of life date and then the Bitcoin keys (BIP32) can be restored.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e Regards\n\u003e\u003e \n\u003e\u003e Chris D'Costa\n\u003e\u003e \n\u003e\u003e Sent from my iPhone\n\u003e\u003e \n\u003e\u003e \u003e On 1 Apr 2014, at 13:32, Jeff Garzik \u003cjgarzik at bitpay.com\u003e wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e Re-reading this, even with the most recent message, is still isn't\n\u003e\u003e \u003e clear _precisely_ how your technology works, or why it is better than\n\u003e\u003e \u003e namecoin. User profiles (and distributed ledgers) need to reflect the\n\u003e\u003e \u003e latest updates, and a stream of updates of over time is precisely what\n\u003e\u003e \u003e bitcoin technology secures.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Keys expire or are compromised, and the public ledger needs to reflect\n\u003e\u003e \u003e that. There is a lot of computer science involved in making sure the\n\u003e\u003e \u003e public ledger you see is not an outdated view. A log-like stream of\n\u003e\u003e \u003e changes is not the only way to do things, but other methods need less\n\u003e\u003e \u003e hand-wavy details (show the code) before they are well recognized as\n\u003e\u003e \u003e useful.\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e\u003e On Mon, Mar 31, 2014 at 7:14 AM, Chris D'Costa \u003cchris.dcosta at meek.io\u003e wrote:\n\u003e\u003e \u003e\u003e Security of transmission of person-to-person pay-to addresses is one of the use cases that we are addressing on our hardware wallet.\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e I have yet to finish the paper but in a nutshell it uses a decentralised ledger of, what we refer to as, \"device keys\".\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e These keys are not related in any way to the Bitcoin keys, (which is why I'm hesitating about discussing it here) neither do they even attempt to identify the human owner if the device. But they do have a specific use case and that is to provide \"advanced knowledge\" of a publickey that can be used for encrypting a message to an intended recipient, without the requirement for a third-party CA, and more importantly without prior dialogue. We think it is this that would allow you to communicate a pay-to address to someone without seeing them in a secure way.\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e As I understand it the BlockChain uses \"time\" bought through proof of work to establish a version of the truth, we are using time in the reverse sense : advanced knowledge of all pubkeys. Indeed all devices could easily check their own record to identify problems on the ledger.\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e There is of course more to this, but I like to refer to the \"distributed ledger of device keys\" as the \"Web-of-trust re-imagined\" although that isn't strictly true.\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e Ok there you have it. The cat is out of the bag, feel free to give feedback, I have to finish the paper, apologies if it is not a topic for this list.\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e Regards\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e Chris D'Costa\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e\u003e On 31 Mar 2014, at 12:21, vv01f \u003cvv01f at riseup.net\u003e wrote:\n\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e \u003e\u003e\u003e Some users on bitcointalk[0] would like to have their vanity addresses\n\u003e\u003e \u003e\u003e\u003e available for others easily to find and verify the ownership over a kind\n\u003e\u003e \u003e\u003e\u003e of WoT. Right now they sign their own addresses and quote them in the\n\u003e\u003e \u003e\u003e\u003e forums.\n\u003e\u003e \u003e\u003e\u003e As I pointed out there already the centralized storage in the forums is\n\u003e\u003e \u003e\u003e\u003e not secury anyhow and signed messages could be swapped easily with the\n\u003e\u003e \u003e\u003e\u003e next hack of the forums.\n\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e \u003e\u003e\u003e Is that use case taken care of in any plans already?\n\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e \u003e\u003e\u003e I thought about abusing pgp keyservers but that would suit for single\n\u003e\u003e \u003e\u003e\u003e vanity addresses only.\n\u003e\u003e \u003e\u003e\u003e It seems webfinger could be part of a solution where servers of a\n\u003e\u003e \u003e\u003e\u003e business can tell and proof you if a specific address is owned by them.\n\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e \u003e\u003e\u003e [0] https://bitcointalk.org/index.php?topic=502538\n\u003e\u003e \u003e\u003e\u003e [1] https://bitcointalk.org/index.php?topic=505095\n\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e \u003e\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e \u003e\u003e\u003e _______________________________________________\n\u003e\u003e \u003e\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e \u003e\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e \u003e\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e \u003e\u003e _______________________________________________\n\u003e\u003e \u003e\u003e Bitcoin-development mailing list\n\u003e\u003e \u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e \u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e --\n\u003e\u003e \u003e Jeff Garzik\n\u003e\u003e \u003e Bitcoin core developer and open source evangelist\n\u003e\u003e \u003e BitPay, Inc. https://bitpay.com/\n\u003e\u003e \n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140402/eb17bb32/attachment.html\u003e",
"sig": "9311cf4ffc896c7edc880dca5bb9030b4f5f262c315125a7d4ff56631a773b67883757d60e24b5a13092cc8bf402abf63c3f95c5dfdded2199ef7dbd980769f3"
}