[bitcoin-dev] trust

[bitcoin-dev] trust

[Thomas Zander]

On Friday 7. August 2015 23.53.43 Adam Back wrote:
> On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
> > As we concluded in our previous email, the need to run a node is inversely
> > proportional to the ability (or willingness) to trust others.
[]
> > And lets face it, practically everyone trusts others with their money
> > today.

> Bitcoin's very reason for existence is to avoid that need.  For people
> fully happy to trust others with their money, Bitcoin may not be as
> interesting to them.

I'm making this a thread of its own because this is very serious.

The idea that Bitcoins very reason for existence is to avoid trusting anyone 
but yourself is something I've heard before, and I have to comment because it 
is a destructive thought. It is very much untrue because we don't live in a 
black/white world.

If you look at the history of money (500 years is enough) you may know about 
business being done in the late 1600s in Europe that included essentially a 
general ledger that every merchant used and had his own copy of (at least 
their own bits).
Merchant in France used a system that when they bought stock from one company
they didn't give them money, they instead gave them a IOU-style piece of 
paper.  To break your promise meant to be evicted from their money system.
Which to a merchant in that time is equal to starvation.

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.


Bitcoins current model to decentralize and distribute trust has historical 
precedent and is known to work. It was abandoned when Newton started the mint 
in London because that allowed international trade. And their system didn't 
scale.


On a tangent;
What we saw with the Internet is growth because of a lack of centralized 
controller. This does not mean lack of trust in your neighbours. Internet grew 
because permissionless innovation was allowed. Not by going from one extreme 
of central trust to the other extreme of no trust.
It flourished just by stepping out of the trust-one party extreme.

What Adam Black and probably some others must understand is that there is a 
whole spectrum between having a monopoly on trust and every player having 
their own node.

Bitcoin sole reason for existence is because it is the first every system that 
has global reach and does not need a central trusted party.
It is, in other words, the first alternative that for the very first time in 
centuries that allows innovation without permission.


> For people
> fully happy to trust others with their money, Bitcoin may not be as
> interesting to them.

So, this is to black/white. And also wrong.

This thinking will block growth towards the thing you want, and leave you 
without any toys at all.
For instance it is perfectly all right to have a central player in a poor 
country that helps millions of unbanked to use Bitcoin as their first 
international payment system.


I can only try to convince you to change your worldview be explaining some 
history and concepts you may have missed, if you don't thats fine with me. 
I do, however, have to ask you to assume people will not like Bitcoin and will 
not use it because they don't fit your worldview. That will ultimately hurt 
billions of people.
-- 
Thomas Zander

Re: [bitcoin-dev] trust

[Adam Back]

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

Re: [bitcoin-dev] trust

[Thomas Zander]

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

Re: [bitcoin-dev] trust

[Benjamin]

[-- Attachment #1: Type: text/plain, Size: 3067 bytes --]

>> 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@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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3922 bytes --]

Re: [bitcoin-dev] trust

[s7r]

-----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@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@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-----

Re: [bitcoin-dev] trust

[Benjamin]

[-- Attachment #1: Type: text/plain, Size: 5378 bytes --]

>>  What is the problem that
you see in lightning model exactly?

How do you know who is who online? If Alice and Bob want to transact and
haven't exchanged keys before they need public-key infrastructure
out-of-band to identify themselves. Which means they are using SSL and
Certificate authorities and trust them. If you have non-cooperative hubs
they could flood the network and make it unusable. And why should hubs
cooperate? There are no incentives in the system.

On Sat, Aug 8, 2015 at 1:08 PM, s7r <s7r@sky-ip.org> wrote:

> -----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@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@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-----
>

[-- Attachment #2: Type: text/html, Size: 6473 bytes --]

Re: [bitcoin-dev] trust

[Joseph Poon]

Hi Benjamin,

On Sat, Aug 08, 2015 at 02:01:58PM +0200, Benjamin via bitcoin-dev wrote:
> How do you know who is who online? 

If a node is not online, then the payment can be cancelled and
re-routed.

> If Alice and Bob want to transact and haven't exchanged keys before
> they need public-key infrastructure out-of-band to identify
> themselves. Which means they are using SSL and Certificate authorities
> and trust them. 

Lightning doesn't solve the key exchange problem (perhaps something like
Namecoin will help in the future). Bitcoin faces this problem today. How
do you know the bitcoin address belongs to the recipient without
trusting CAs? What if, in the case of the majority of bitcoin payments
today, the bitcoin address was not signed and the recipient claimed to
have never received their funds? There should be signed proof of payment
in every transaction for this reason.

> If you have non-cooperative hubs they could flood the network and make
> it unusable. And why should hubs cooperate? There are no incentives in
> the system.

There are some incentives towards keeping the system functional via
fees. If you attempt to flood the system, you'll likely be paying some
fees -- someone running a node will not interpret it as an attack, as
they're getting some money (probabably substantially higher as they will
increase fees to ensure network availability).

I agree that it's very important to think through varius attack models.

-- 
Joseph Poon

Re: [bitcoin-dev] trust

[Milly Bitcoin]

> Trust takes many different forms and is not a binary function.

Many Bitcoiners have a rather unusual notion of trust.  While many state 
the established financial systems cannot be trusted they imply that many 
within the Bitcoin world need to be trusted.   There are some very 
irresponsible and unusual people who have authority to do things in the 
Bitcoin world such as manage the Wiki, the Github repository, and are 
given an emergency alert key.  Some of these people are only known by 
some sort of screen name.  If anyone questions any of these processes 
they are chastised and labeled a "troll".  For instance, anyone who 
questioned Mt. Gox back in 2013 was labeled a "buttcoiner" or something 
similar.  So I would say many people, including many on this list, don't 
fully understand the claims they are making about the "truslessness" of 
Bitcoin.

 >Lightning doesn't require explicit trust,

There seems to be semantic issues with describing trust and the 
lightning network.  You need to trust the other party during the 
transactions in the channel for it to work.  Yes there is way to cash 
out if the other party does not cooperate but that is not the same thing 
as saying it is trustless.  Many people are confused about this part of 
decentralization where the network has to take time to reach consensus. 
  Some people think that you can use some kind of technological trick to 
avoid this lag time and still have a completely trustless system.  It is 
a tradeoff.

Russ

Re: [bitcoin-dev] trust

[Adam Back]

On 8 August 2015 at 09:54, Thomas Zander <thomas@thomaszander.se> wrote:
> I didn't say off-chain, and gave an example of on-chain usecase with trusted middleman.

That's basically the definition of off-chain.  When we say MtGox or
coinbase etc are off-chain transactions, that is because a middle man
has the private keys to the coins and gave you an IOU of some kind.

Adam

Re: [bitcoin-dev] trust

[Thomas Zander]

On Saturday 8. August 2015 12.54.36 Adam Back wrote:
> On 8 August 2015 at 09:54, Thomas Zander <thomas@thomaszander.se> wrote:
> > I didn't say off-chain, and gave an example of on-chain usecase with
> > trusted middleman.
> That's basically the definition of off-chain.  When we say MtGox or
> coinbase etc are off-chain transactions, that is because a middle man
> has the private keys to the coins and gave you an IOU of some kind.

I'm so sorry to have to correct you again, and please don't feel bad about 
misreading my post twice.

Sending something to another Bitcoin on-chain user is really on-chain. Please 
believe me when I say that I actually understand my own example.

-- 
Thomas Zander

Re: [bitcoin-dev] trust

[Jorge Timón]

On Sat, Aug 8, 2015 at 2:37 PM, Thomas Zander via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Saturday 8. August 2015 12.54.36 Adam Back wrote:
>> On 8 August 2015 at 09:54, Thomas Zander <thomas@thomaszander.se> wrote:
>> > I didn't say off-chain, and gave an example of on-chain usecase with
>> > trusted middleman.
>> That's basically the definition of off-chain.  When we say MtGox or
>> coinbase etc are off-chain transactions, that is because a middle man
>> has the private keys to the coins and gave you an IOU of some kind.
>
> I'm so sorry to have to correct you again, and please don't feel bad about
> misreading my post twice.
>
> Sending something to another Bitcoin on-chain user is really on-chain. Please
> believe me when I say that I actually understand my own example.

Adam, I think he means a multisig escrow transaction where the escrow
is trusted by both parties, and other examples like that.
But I don't see how that is relevant, allowing trust to be involved in
different ways is a feature, but it's optional.
I think the point "you don't need to trust anyone to use Bitcoin" remains.

Re: [bitcoin-dev] trust

[Milly Bitcoin]

> I think the point "you don't need to trust anyone to use Bitcoin" remains.

I don't think that is a true statement.  Users need to trust the mining 
system is working as intended.  Users also need to trust the developers 
to a certain extent.  It is about levels of trust and how much you need 
to trust these things.  When someone says something is "trustless" or 
"decentralized" they are really saying that it reaches some sort of 
"acceptable" level in their mind to "brand" it that way.

Russ

Re: [bitcoin-dev] trust

[Thomas Zander]

On Monday 10. August 2015 22.17.52 Jorge Timón wrote:
> But I don't see how that is relevant, allowing trust to be involved in
> different ways is a feature, but it's optional.

Agreed.

> I think the point "you don't need to trust anyone to use Bitcoin" remains.

yes, and thats fine.


The argument that Adam was making was the other extreme; that Bitcoin was 
useless the moment he has to trust any 3rd party.
And that is why I started this thread, because that idea that Bitcoin looses 
its functionality when you deviate from the trust-no-one path, is destructive.


For instance I suggested a week ago that the Chinese firewall (blocksize 
propagation) problem could maybe be solved by having a chinese miner partially 
trust some full nodes on Internet hubs. For instance in Amsterdam, one in 
Stockholm, etc.
And then propagation of a newly mined block would make the miner only sent the 
header to this server where a full x-MB block is then created by some 
specialized software that bases it on the mempool of its bitcoind.

Propagation of a Chinese miner then suddenly doesn't care about blocksize when 
hopping over the chinese firewall. You'd only send a small amount of data, 
likely around 20Kb for even 8Mb blocks.

A critic would argue its a useless strategy because you'd have to trust the 
data center operators.
I'd argue that its a risk, for sure, but one that can be mitigated easily by 
having various datacenters around the world where you'd run your software so 
you'd be able to check the validity of each.

Risks can only be assessed fairly if people are less black/white in their 
thinking.

I love that about Bitcoin, it combines technical specialized thinking with 
Economics and planning. If you don't have both, you probably end up rejecting 
the best ideas.


> Adam, I think he means a multisig escrow transaction where the escrow
> is trusted by both parties, and other examples like that.

Yes, thats one example. Thanks Jorge!

A similar but relevant example would be like the M-Pesa example.
People that have a phone but not a smart phone can choose to have their 
private keys stored at a trusted company in their own country. Some payments 
can be off-chain, but as soon as you deal with people outside of this small 
community they would be on-chain.

When we are talking about remittances, this means one of the two parties does 
not have an account at the trusted party and as such this will be an on-chain 
transaction.
Same for a farmer in Nairobi buying equipment from a company in Cairo, or a 
Internet startup in Kampala/Uganda selling services to users in Europe and 
those users send their payments on-chain.

All of these examples are about the largest group of people in the world; the 
unbanked. Bitcoin could mean a huge change to these people and I care a lot 
about this usecase. We need bigger bocks for these usecases as LN will not do 
anything for them.

-- 
Thomas Zander

Re: [bitcoin-dev] trust

[Venzen Khaosan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/08/2015 01:10 PM, Thomas Zander via bitcoin-dev wrote:
> On Friday 7. August 2015 23.53.43 Adam Back wrote:
>> On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
>>> As we concluded in our previous email, the need to run a node
>>> is inversely proportional to the ability (or willingness) to
>>> trust others.
> []
>>> And lets face it, practically everyone trusts others with their
>>> money today.
> 
>> Bitcoin's very reason for existence is to avoid that need.  For
>> people fully happy to trust others with their money, Bitcoin may
>> not be as interesting to them.
> 
> I'm making this a thread of its own because this is very serious.
> 
> The idea that Bitcoins very reason for existence is to avoid
> trusting anyone but yourself is something I've heard before, and I
> have to comment because it is a destructive thought. It is very
> much untrue because we don't live in a black/white world.

I think the context is not that "Bitcoin's reason for existence is to
avoid trusting anyone but yourself", as you state above. This kind of
dystopia is not, in my view, what the advocates of trustlessness and
security are implying.

There are those instances where we have no option other than to trust
a centralized authority. They are mostly self-appointed and do not
have the interests of the rest of us in mind. The central bank is the
obvious example - they impose their currency as "official" and then
devalue our savings and purchasing power through money supply
inflation - without our permission and in betrayal of the trust
relationship.  Bitcoin allows one to hold money and to conduct money
transactions, transmit value, and so forth without having to trust
*them* - the central bank, or anyone.

In another example, we want to conduct escrow and have to trust the
notary, because of his reputation and framed certificate, but Bitcoin
multisig makes the degree of trust between the escrow parties
irrelevant, so no apparently trustworthy "gentleman" merchant (back
then or now) can socially engineer a transaction and scam us.

I don't know if my reply and its examples is over-simplistic but it
seems you were making a moral appeal that the notion of trustlessness
was destructive - I just wanted to contextualize it to relevant use
cases. It follows, and this is what I understand from Adam's message,
that security and protection of decentralization are paramount
concerns if we want to retain the trustlessness that makes Bitcoin so
useful and powerful.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVxcZSAAoJEGwAhlQc8H1mmAUH/RprBA/tz13/CIJTQ4HHYU5v
kBAyirwhkx5NEvovFGV40PNpIE7OLqfoN2ThpwJSO8fqnPwbcGEr1qvZAaN9A68y
GD1sjw2y+8+hQUtrikMurBFzCX4msBvfYNPHX4J7SBR9qdxC9L7p6HaY5fvdwpQW
DmUMidKuRPpWH5AL9DqB9ZwHtPZ8mVaJGHMw1aI9QV0cTlq49ktbt/246wAjtRkb
Myw2c9hKT2WIwzmWcruokSXJ4yza6DGYKrcyzprIDCJFEj29geoIderyU+0qzRQ7
julB3Ft05xp2F6LheeH40wa7iyeRs6LWRNr2qElutu6Ta7Rvlg5ZCUGN52SGQtY=
=3rcg
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] trust

[Gregory Maxwell]

On Sat, Aug 8, 2015 at 6:10 AM, Thomas Zander via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> The idea that Bitcoins very reason for existence is to avoid trusting anyone
> but yourself is something I've heard before, and I have to comment because it
> is a destructive thought. It is very much untrue because we don't live in a
> black/white world.
[...]
> 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.


I think you are drawing a disction that does not exist; rather it's a
disagreement about terminology.

If a system exists that provides high confidence of faithful behavior
even from malicious parties, then it's one this community would call
"trustless" (assuming the security properties are strong enough).
The result is a system where it's possible to trust everyone.

Trust in this case has multiple meanings.   In one meaning trust is an
(well founded) expectation of faithful behavior.  In another it is a
blind reliance.   When "trust everyone" is used, it's speaking to the
first definition, when the trustless definition is used it's referring
to the second defintion-- without blind faith.

A trustless (second def) system allows its users to trust (first def)
everyone, even the inherently untrustworthy (second def).  In doing
so, the considerable cost and inequality created by the maintaince of
trust (second definition) relations is mitigated, and the availablity
of faithful performance increased.  Doing so is a prerequsite to
having a strongly decenteralized system, because otherwise trust
requiremets drive the enviroment towards natural monopolies (as it's
cheaper and more effective for more people to trust (second def) a
smaller number of parties.

Less philosophically, if you're willing to have systems defined by
trust (first definition) (e.g. you do not believe that what I descibed
above coveys value, or hope that witl a small number of very trusted
parties external factors will transform blind faith into a rational
expectation of faithful performance) then there are _much_ more
technically superior ways to structure a system than Bitcoin does
today-- ones that acheive much greater performance, flexibility,
reliablity, and better security (ignoring any insecurity that arises
as a result of the trusted parties strong assumptions).

If one wants to layer trust based things on top of a trust mitigating
framework, they can do so-- and enjoy efficiencies from doing so.
Doing the converse doesn't appear really possible.