s7r [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-08 📝 Original message:-----BEGIN PGP SIGNED ...
📅 Original date posted:2015-08-08
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Interesting point of view Thomas! I agree that if we only think
towards one single direction (treat trust as a super bad thing) we
might miss some good features (or scalability levels) among the way.
Benjamin:
> Lightning assumes explicit trust and ID - much like Ripple. That's
> not going to work, and I'm surprised that someone with basic
> knowledge of crypto doesn't see this problem. Having explicit
> counter-parties is something very different from Bitcoin where the
> entity doing transactions verification is unknowable and changes
> all the time.
Can explain why exactly do you think this? What is the problem that
you see in lightning model exactly? I am not arguing, maybe you are
right and there is a part of the lightning network proposal which I
missed, so that is why I am asking for clarification here.
Lightning doesn't require explicit trust, worst case scenario you can
end up with coins blocked until next in-chain broadcast. It depends on
each and very hub, obviously there will also be trusted, identified
public hubs but we can also have anonymous hubs.
On 8/8/2015 12:24 PM, Benjamin via bitcoin-dev wrote:
>>> The point was NOT to trust no-one, the point was to trust
>>> everyone, but keep everyone honest by keeping the ledger open
>>> and publicly available.
>
> Trust takes many different forms and is not a binary function. You
> trust a surgeon to do an operation and a pilot to fly a jet, but
> not vice versa. To trust someone explicitly, you need to know who
> they are. Most social structures work without explicit identity and
> they still function quite well. For example companies are mostly
> anonymous to the consumer - if you buy something in a shop you
> trust a chain of people producing that good. A priori there is
> little reason to trust others, but rather that trust is already
> developed through social institutions. Money is one such
> institution with specific trust problems, and the history of money
> is indeed a very good way to study these problems. Unfortunately in
> Bitcoin development such insights are rare to find.
>
> Lightning assumes explicit trust and ID - much like Ripple. That's
> not going to work, and I'm surprised that someone with basic
> knowledge of crypto doesn't see this problem. Having explicit
> counter-parties is something very different from Bitcoin where the
> entity doing transactions verification is unknowable and changes
> all the time. Users of Bitcoin trust nodes doing the verification
> because they know it is in their best interest to be honest.
> Neither Sidechains nor LT have preserve that important property,
> and so IMO there are no good proposals to make Bitcoin scale (if
> that is possible at all).
>
> On Sat, Aug 8, 2015 at 10:54 AM, Thomas Zander via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I didn't say off-chain, and gave an example of on-chain usecase
> with trusted middleman.
>
> So, no, that's not what I meant.
>
> Sent on the go, excuse the brevity. Original Message From: Adam
> Back Sent: Saturday, 8 August 2015 09:50 To: Thomas Zander Cc:
> Bitcoin Dev Subject: Re: [bitcoin-dev] trust
>
> If you are saying that some people are happy trusting other
> people, and so would be perfectly fine with off-chain use of
> Bitcoin, then we agree and I already said that off-chain use case
> would be a constructive thing for someone to improve scale and
> interoperability of in the post you are replying to. However that
> use case is not a strong argument for weakening Bitcoin's security
> to get to more scale for that use case.
>
> In a world where we could have scale and decentralisation, then of
> course it would be nice to provide people with that outlook more
> security than they seem to want. And sometimes people dont
> understand why security is useful until it goes wrong, so it would
> be a useful thing to do. (Like insurance, your money being seized
> by paypal out of the blue etc). And indeed providing security at
> scale maybe possible with lightning like protocols that people are
> working on.
>
> Adam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJVxeMaAAoJEIN/pSyBJlsRJFoH/RbgArUMJStQwF92XZk99dUd
0xI/VU1goFLDFiFVkrea7uNWUrWw0GM9nDq0kTIV+mTi9rTYgWKlgA1XZnPusr35
GpDhXxoG3mJmay9AX1fezrZjGmCZPCjSnPWa+BeQCSMXnVchZX0U4XZSwgD7qTIU
7o4r5JIDuGxXyPcwECnB7ePmZ8xA2QGQaMW6nnMhlA4KCanSd5/78kcpUp/kGAJ1
chjhV2g7tAeq3NMs2IXeIMiEAqji0B7RRAejviBg9CAwbpo4dP3dRz8hv/qPx6K0
Mu6jHczCQOUyAHagwG8q4+laMbkskVETw18NwluspOZi3inxvVpOD60CDqSZPS4=
=ogMZ
-----END PGP SIGNATURE-----
Published at
2023-06-07 17:34:21Event JSON
{
"id": "572cfb1f15b3c4a1f9324125d9d16d7d403a7c58cda2dba7feb1a255ced118ea",
"pubkey": "947955301a8805054c8d6a2c9ac2abf07a7a18f4a33b0a573a277868302953b1",
"created_at": 1686159261,
"kind": 1,
"tags": [
[
"e",
"8287fb098149738a433b7bc4acef5eade09e0f2c6dee917fd5ff21406103ee42",
"",
"root"
],
[
"e",
"a09cb4fdcbb269addc53eb0a49a2c2a15b6050c4c4e2404d9f07001ee936c859",
"",
"reply"
],
[
"p",
"f5854a07c480aa95b00a3106a17778f7b58221d8dd12d11e6d9465ba737bd50c"
]
],
"content": "📅 Original date posted:2015-08-08\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nInteresting point of view Thomas! I agree that if we only think\ntowards one single direction (treat trust as a super bad thing) we\nmight miss some good features (or scalability levels) among the way.\n\nBenjamin:\n\u003e Lightning assumes explicit trust and ID - much like Ripple. That's\n\u003e not going to work, and I'm surprised that someone with basic\n\u003e knowledge of crypto doesn't see this problem. Having explicit\n\u003e counter-parties is something very different from Bitcoin where the\n\u003e entity doing transactions verification is unknowable and changes\n\u003e all the time.\n\nCan explain why exactly do you think this? What is the problem that\nyou see in lightning model exactly? I am not arguing, maybe you are\nright and there is a part of the lightning network proposal which I\nmissed, so that is why I am asking for clarification here.\n\nLightning doesn't require explicit trust, worst case scenario you can\nend up with coins blocked until next in-chain broadcast. It depends on\neach and very hub, obviously there will also be trusted, identified\npublic hubs but we can also have anonymous hubs.\n\nOn 8/8/2015 12:24 PM, Benjamin via bitcoin-dev wrote:\n\u003e\u003e\u003e The point was NOT to trust no-one, the point was to trust\n\u003e\u003e\u003e everyone, but keep everyone honest by keeping the ledger open\n\u003e\u003e\u003e and publicly available.\n\u003e \n\u003e Trust takes many different forms and is not a binary function. You\n\u003e trust a surgeon to do an operation and a pilot to fly a jet, but\n\u003e not vice versa. To trust someone explicitly, you need to know who\n\u003e they are. Most social structures work without explicit identity and\n\u003e they still function quite well. For example companies are mostly\n\u003e anonymous to the consumer - if you buy something in a shop you\n\u003e trust a chain of people producing that good. A priori there is\n\u003e little reason to trust others, but rather that trust is already\n\u003e developed through social institutions. Money is one such\n\u003e institution with specific trust problems, and the history of money\n\u003e is indeed a very good way to study these problems. Unfortunately in\n\u003e Bitcoin development such insights are rare to find.\n\u003e \n\u003e Lightning assumes explicit trust and ID - much like Ripple. That's\n\u003e not going to work, and I'm surprised that someone with basic\n\u003e knowledge of crypto doesn't see this problem. Having explicit\n\u003e counter-parties is something very different from Bitcoin where the\n\u003e entity doing transactions verification is unknowable and changes\n\u003e all the time. Users of Bitcoin trust nodes doing the verification\n\u003e because they know it is in their best interest to be honest.\n\u003e Neither Sidechains nor LT have preserve that important property,\n\u003e and so IMO there are no good proposals to make Bitcoin scale (if\n\u003e that is possible at all).\n\u003e \n\u003e On Sat, Aug 8, 2015 at 10:54 AM, Thomas Zander via bitcoin-dev \n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e I didn't say off-chain, and gave an example of on-chain usecase\n\u003e with trusted middleman.\n\u003e \n\u003e So, no, that's not what I meant.\n\u003e \n\u003e Sent on the go, excuse the brevity. Original Message From: Adam\n\u003e Back Sent: Saturday, 8 August 2015 09:50 To: Thomas Zander Cc:\n\u003e Bitcoin Dev Subject: Re: [bitcoin-dev] trust\n\u003e \n\u003e If you are saying that some people are happy trusting other\n\u003e people, and so would be perfectly fine with off-chain use of\n\u003e Bitcoin, then we agree and I already said that off-chain use case\n\u003e would be a constructive thing for someone to improve scale and\n\u003e interoperability of in the post you are replying to. However that\n\u003e use case is not a strong argument for weakening Bitcoin's security\n\u003e to get to more scale for that use case.\n\u003e \n\u003e In a world where we could have scale and decentralisation, then of \n\u003e course it would be nice to provide people with that outlook more \n\u003e security than they seem to want. And sometimes people dont\n\u003e understand why security is useful until it goes wrong, so it would\n\u003e be a useful thing to do. (Like insurance, your money being seized\n\u003e by paypal out of the blue etc). And indeed providing security at\n\u003e scale maybe possible with lightning like protocols that people are\n\u003e working on.\n\u003e \n\u003e Adam\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2.0.22 (MingW32)\n\niQEcBAEBCAAGBQJVxeMaAAoJEIN/pSyBJlsRJFoH/RbgArUMJStQwF92XZk99dUd\n0xI/VU1goFLDFiFVkrea7uNWUrWw0GM9nDq0kTIV+mTi9rTYgWKlgA1XZnPusr35\nGpDhXxoG3mJmay9AX1fezrZjGmCZPCjSnPWa+BeQCSMXnVchZX0U4XZSwgD7qTIU\n7o4r5JIDuGxXyPcwECnB7ePmZ8xA2QGQaMW6nnMhlA4KCanSd5/78kcpUp/kGAJ1\nchjhV2g7tAeq3NMs2IXeIMiEAqji0B7RRAejviBg9CAwbpo4dP3dRz8hv/qPx6K0\nMu6jHczCQOUyAHagwG8q4+laMbkskVETw18NwluspOZi3inxvVpOD60CDqSZPS4=\n=ogMZ\n-----END PGP SIGNATURE-----",
"sig": "5e0a4eb2ba5093fe39b022a5fab521485c4f9c7e27923360e46ea0cc0a8c8756831b5154ec689d65ce78426e5fef1c974b685b9ab72f4f4152cad585b5fdca7e"
}