📅 Original date posted:2014-06-19
📝 Original message:> Supporting it in the protocol is easy. Building such a thing: that's
hard. Decentralised automated reputation systems are complex and subtle.
Bitcoin is valuable as a protocol because it is truly decentralized. The
complexity involved in building this system was expansive, but I think we
can all agree it was worth the trouble. With this particular topic of
instant transactions it seems we have to be very careful about pushing
Bitcoin in a centralized direction for the sake of a simple quick solution.
Building an automated system to solve the instant transaction problem will
be difficult, but also well worth the effort, and exactly like you're
saying Mike, I just want to make sure the door is left open protocol wise
for a robust solution in the future.
On Wed, Jun 18, 2014 at 9:09 AM, Mike Hearn <mike at plan99.net> wrote:
> I think that's true if you assume that the instant provider list is based
>> on a by hand created list of accepted instant providers. That's how VISA
>> works now and that's why I was asking for an approach where the
>> trusted_instant_providers list is scalable because that seems very
>> dangerous.
>>
>
> Supporting it in the protocol is easy. Building such a thing: that's hard.
> Decentralised automated reputation systems are complex and subtle.
>
> I don't feel strongly about whether the field should be "optional" or
> "repeated", 100% of implementations in the forseeable future would just
> look at the first item and ignore the rest. But if later someone did crack
> this problem it would lead to a simple upgrade path. So perhaps you're
> right and the protobuf should allow multiple signatures. It means a new
> sub-message to wrap the pki_type, pki_data and signature fields into one,
> and then making that repeated.
>
> Up to Lawrence.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140619/29c44805/attachment.html>;
Daniel Rice [ARCHIVE] /
npub1mn…3vect
2023-06-07 15:22:42
in reply to nevent1q…2hev
Author Public Key
npub1mn37wn20kd63upafw66dncxceyvfud6ceyjj37st94a9qlnsrweqn3vectPublished at
2023-06-07 15:22:42Event JSON
{
"id": "e27b040bea7592a1e047060510ac25fc6c8a878befbc7b56312608bfb876ee9a",
"pubkey": "dce3e74d4fb3751e07a976b4d9e0d8c9189e3758c92528fa0b2d7a507e701bb2",
"created_at": 1686151362,
"kind": 1,
"tags": [
[
"e",
"ed0eede28e160c2ef8ddd5af1ee3069fdb0eb5f4c939c1c09a1a5f338c30c628",
"",
"root"
],
[
"e",
"67458821e26a5d7bafc58184d8a2cd287aad61aaa267eb6d312748c5362f6545",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-06-19\n📝 Original message:\u003e Supporting it in the protocol is easy. Building such a thing: that's\nhard. Decentralised automated reputation systems are complex and subtle.\n\nBitcoin is valuable as a protocol because it is truly decentralized. The\ncomplexity involved in building this system was expansive, but I think we\ncan all agree it was worth the trouble. With this particular topic of\ninstant transactions it seems we have to be very careful about pushing\nBitcoin in a centralized direction for the sake of a simple quick solution.\nBuilding an automated system to solve the instant transaction problem will\nbe difficult, but also well worth the effort, and exactly like you're\nsaying Mike, I just want to make sure the door is left open protocol wise\nfor a robust solution in the future.\n\n\nOn Wed, Jun 18, 2014 at 9:09 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\n\u003e I think that's true if you assume that the instant provider list is based\n\u003e\u003e on a by hand created list of accepted instant providers. That's how VISA\n\u003e\u003e works now and that's why I was asking for an approach where the\n\u003e\u003e trusted_instant_providers list is scalable because that seems very\n\u003e\u003e dangerous.\n\u003e\u003e\n\u003e\n\u003e Supporting it in the protocol is easy. Building such a thing: that's hard.\n\u003e Decentralised automated reputation systems are complex and subtle.\n\u003e\n\u003e I don't feel strongly about whether the field should be \"optional\" or\n\u003e \"repeated\", 100% of implementations in the forseeable future would just\n\u003e look at the first item and ignore the rest. But if later someone did crack\n\u003e this problem it would lead to a simple upgrade path. So perhaps you're\n\u003e right and the protobuf should allow multiple signatures. It means a new\n\u003e sub-message to wrap the pki_type, pki_data and signature fields into one,\n\u003e and then making that repeated.\n\u003e\n\u003e Up to Lawrence.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140619/29c44805/attachment.html\u003e",
"sig": "96ba29d1e2f915c9359b222fc8b7d0a448d84bb93e79a3049fe432d657a52c010cffe08b2b0c7d2bda609f53ed148bd17bbf05fb56fb01346e959c67762e311a"
}