📅 Original date posted:2014-06-16
📝 Original message: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.
What if the protocol allowed multiple instant signatures on a transaction?
Would it encourage more instant providers? For example, a new instant
provider could bootstrap their own trust by paying an already trusted
instant provider to co-sign the same transaction. This would be useful in
the case that a new company tries to release a new wallet once the trust
ring is already established. Nobody will use that wallet because it does
not have the trusted history to do instant transactions, but if they can
pay a small amount per transaction to a third party to cosign, they can
build trust in their own signature till they can eventually have enough
trust on their own. This could be how an individual user could grow trust
in their own instant signature as well.
On Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn <mike at plan99.net> wrote:
> I think many of us feel it'd be better if this kind of thing were not
> needed at all, however, the best way to ensure it doesn't end up being used
> is to write code, not to try and block alternative approaches. If Bitcoin
> is robust the market should sort it out. If it's robust for some
> transactions and not others, that makes for a fun project for a future
> generation of hackers to sort out.
>
> OK, enough philosophy - let's try and keep this thread just for discussion
> of the BIP itself from now on. If you'd like to continue debating the
> Future of Bitcoin please change the subject line and break it out into a
> new thread.
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> 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/20140616/d9d757fa/attachment.html>;
Daniel Rice [ARCHIVE] /
npub1mn…3vect
2023-06-07 15:22:47
in reply to nevent1q…g4xd
Author Public Key
npub1mn37wn20kd63upafw66dncxceyvfud6ceyjj37st94a9qlnsrweqn3vectPublished at
2023-06-07 15:22:47Event JSON
{
"id": "1b37a5c1b1fb0fe1ca7ddb6e23d39993a7b65b5d5212c5b374958430b97ec803",
"pubkey": "dce3e74d4fb3751e07a976b4d9e0d8c9189e3758c92528fa0b2d7a507e701bb2",
"created_at": 1686151367,
"kind": 1,
"tags": [
[
"e",
"ed0eede28e160c2ef8ddd5af1ee3069fdb0eb5f4c939c1c09a1a5f338c30c628",
"",
"root"
],
[
"e",
"41d5ab667a050f5886d9e9170374f6d75a92d743dc7b09567884d6fae2e5be8b",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-06-16\n📝 Original message:I'm trying to think through how to encourage the maximum number of instant\nsignature providers and avoid the VISA monopoly. Ideal case would be that\npeople can even be their own instant provider.\n\nWhat if the protocol allowed multiple instant signatures on a transaction?\nWould it encourage more instant providers? For example, a new instant\nprovider could bootstrap their own trust by paying an already trusted\ninstant provider to co-sign the same transaction. This would be useful in\nthe case that a new company tries to release a new wallet once the trust\nring is already established. Nobody will use that wallet because it does\nnot have the trusted history to do instant transactions, but if they can\npay a small amount per transaction to a third party to cosign, they can\nbuild trust in their own signature till they can eventually have enough\ntrust on their own. This could be how an individual user could grow trust\nin their own instant signature as well.\n\n\nOn Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\n\u003e I think many of us feel it'd be better if this kind of thing were not\n\u003e needed at all, however, the best way to ensure it doesn't end up being used\n\u003e is to write code, not to try and block alternative approaches. If Bitcoin\n\u003e is robust the market should sort it out. If it's robust for some\n\u003e transactions and not others, that makes for a fun project for a future\n\u003e generation of hackers to sort out.\n\u003e\n\u003e OK, enough philosophy - let's try and keep this thread just for discussion\n\u003e of the BIP itself from now on. If you'd like to continue debating the\n\u003e Future of Bitcoin please change the subject line and break it out into a\n\u003e new thread.\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions\n\u003e Find What Matters Most in Your Big Data with HPCC Systems\n\u003e Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.\n\u003e Leverages Graph Analysis for Fast Processing \u0026 Easy Data Exploration\n\u003e http://p.sf.net/sfu/hpccsystems\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\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/d9d757fa/attachment.html\u003e",
"sig": "2ae717ec3f12c4213393c5f68c7ab8a954651c13ada98048bdaa4146b1c9023ad51e7a5a6fba4028bda3def87c27abf7c39c4d26786ab5e370c58091221b97b8"
}