From: Thomas Zander <thomas@thomaszander.se>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Mon, 10 Aug 2015 23:43:46 +0200
Message-ID: <2674312.GqtxTJeqiO@coldstorage>
User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <CABm2gDrJH8-6VPp1Lk4ueJA2ShOU+evTgK-S1zNjuqN8h8Je+Q@mail.gmail.com>
References: <8185694.hShCHQnpze@coldstorage> <1725491.c810VbMBxP@coldstorage>
	<CABm2gDrJH8-6VPp1Lk4ueJA2ShOU+evTgK-S1zNjuqN8h8Je+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Subject: Re: [bitcoin-dev] trust
Precedence: list

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

Agreed.

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

yes, and thats fine.


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


For instance I suggested a week ago that the Chinese firewall (blocksiz=
e=20
propagation) problem could maybe be solved by having a chinese miner pa=
rtially=20
trust some full nodes on Internet hubs. For instance in Amsterdam, one =
in=20
Stockholm, etc.
And then propagation of a newly mined block would make the miner only s=
ent the=20
header to this server where a full x-MB block is then created by some=20=

specialized software that bases it on the mempool of its bitcoind.

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

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

Risks can only be assessed fairly if people are less black/white in the=
ir=20
thinking.

I love that about Bitcoin, it combines technical specialized thinking w=
ith=20
Economics and planning. If you don't have both, you probably end up rej=
ecting=20
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=
=20
private keys stored at a trusted company in their own country. Some pay=
ments=20
can be off-chain, but as soon as you deal with people outside of this s=
mall=20
community they would be on-chain.

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

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

--=20
Thomas Zander