Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-06-16 📝 Original message:On Mon, Jun 16, 2014 at ...
📅 Original date posted:2014-06-16
📝 Original message:On Mon, Jun 16, 2014 at 10:29 PM, Daniel Rice <drice at greenmangosystems.com>
wrote:
> I'm trying to think through how to encourage the maximum number of instant
> signature providers and avoid the VISA monopoly. Ideal case would be that
> people can even be their own instant provider.
>
A provider does not have to be an interactive third party. One reason I
suggested using X.509 is so secure hardware devices like the TREZOR could
also be instant providers. The hardware would be tamperproof and assert
using a secret key embedded in it that the tx came from a genuine,
unflashed TREZOR. The the server can know the device won't double spend.
In this way you have decentralised anti-double spending. Of course, it's an
old solution. MintChip sort of worked a bit like this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/263c333e/attachment.html>
📝 Original message:On Mon, Jun 16, 2014 at 10:29 PM, Daniel Rice <drice at greenmangosystems.com>
wrote:
> I'm trying to think through how to encourage the maximum number of instant
> signature providers and avoid the VISA monopoly. Ideal case would be that
> people can even be their own instant provider.
>
A provider does not have to be an interactive third party. One reason I
suggested using X.509 is so secure hardware devices like the TREZOR could
also be instant providers. The hardware would be tamperproof and assert
using a secret key embedded in it that the tx came from a genuine,
unflashed TREZOR. The the server can know the device won't double spend.
In this way you have decentralised anti-double spending. Of course, it's an
old solution. MintChip sort of worked a bit like this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/263c333e/attachment.html>