public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Smart Contracts Unchained
Date: Mon, 08 Apr 2019 10:45:29 +0000	[thread overview]
Message-ID: <GkSgHQYXGen75-KP_N2VbK1EmY5DSDe0sncJBU77l6_2xdYhh9Yw5rQSgtPuwXJnMlnA0j195hkMfhnxhGkMERa3kXXW6KvR5qt88oSNGvY=@protonmail.com> (raw)
In-Reply-To: <392367fe-b1d7-7d47-01de-ebb4b7142ead@gmail.com>

Good morning Aymeric,

> Hi,
>
> Apparently you are not a fan of ethereum, as far as I can tell ethereum
> sidechains look like a mess with stupid tokens/transactions flooding the
> network while they are completely centralized, but some bitcoin
> sidechains can easily compete with this too, like Tether, don't even
> understand how anyone can give some credit to that stuff the way it is
> implemented, and if bitcoin fails that would be the same as for ethereum

I prefer to be more precise in my terminology.
Colored coins are not the same as sidechains, and there are colored coins and then there are colored coins.
This mechanism does not propose some change in colored coins.
An important aspect of colored coins is that one can foist them on somebody else to extract things of real value from them, but this mechanism is more strongly for a fixed set of participants.

I strongly suspect that Bitcoin will outlast Ethereum, but that is rather not very related to this topic.

> Most likely everyone would agree if the escrow disappears, but not sure
> at all, let's imagine 1 to N put 10K on the table for a game, they
> update the states and at the end N wins everything, N is rich and don't
> care finally if the others cheaters have their coins locked (and to lose
> 10K), same with setting up a new escrow to resolve the conflict
>

Indeed.
Still, the option to do so exists, and sometimes all that is needed for humans to do the right thing, is to be given the option to do so.

> I think that you should highlight this (and what private key corresponds
> to E + h(E | s) * G, not sure it's trivial for everybody), probably a
> way to get this more decentralized is to reward the escrows (what is the
> interest here for people to run a smart contract platform?)

I assumed both were obvious, but I suppose a few more words about those would not be amiss.

>
> For lightning, maybe it's a question of wording, I consider it as a
> sidechain AND methods that can be used by other sidechains, as well as
> the others you quoted, even if only two people in the world use
> lightning, it is still decentralized, because it sustains itself alone

Again, I prefer precision in my terminology.
For me, a sidechain is a blockchain of some sort.
In particular, a kind of Merklized singly-linked list containing representations of transformations of state, is how I define blockchain to be.

No such Merklized singly-linked list exists in Lightning Network, thus I do not consider it, "blockchain".
And thus I do not consider it "sidechain", as a sidechain is a blockchain.
Current LN does use "shachains" by Rusty, but shachains are not Merklized singly-linked lists, but are instead a kind of inverse mountain range structure.

Still, one might consider both federated sidechains and Lightning Network to have a "federated" offchain structure.
This is because the coins on the Bitcoin blockchain are locked to a multisignature and activity is not recorded on the Bitcoin blockchain.
However, in LN, each channel is a 2-member federation (you and a counterparty) and the mechanism in LN requires consensus (2-of-2) rather than a quorum (m-of-n).
This greatly increases the security of LN: the owner of funding on an LN channel can always refuse to sign an update if the other member of the federation is taken over.
Compare this to the quorum that typical federations have, where takeover of a sufficient quorum is enough to steal funds from the remaining federation.
https://zmnscpxj.github.io/offchain/safety.html

Regards,
ZmnSCPxj


  reply	other threads:[~2019-04-08 10:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-04  1:55 [bitcoin-dev] Smart Contracts Unchained ZmnSCPxj
2019-04-04  2:35 ` Tamas Blummer
2019-04-04  3:37 ` Ariel Lorenzo-Luaces
2019-04-04  7:07   ` ZmnSCPxj
2019-04-04 15:03 ` ZmnSCPxj
2019-04-04 17:18 ` Aymeric Vitte
2019-04-04 23:52   ` ZmnSCPxj
2019-04-05 17:46     ` Aymeric Vitte
2019-04-08 10:45       ` ZmnSCPxj [this message]
2019-04-08 16:28         ` Aymeric Vitte
2019-04-05  6:00 ` ZmnSCPxj
2019-04-17 16:17 ` Nadav Kohen
2019-04-18  5:33   ` ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='GkSgHQYXGen75-KP_N2VbK1EmY5DSDe0sncJBU77l6_2xdYhh9Yw5rQSgtPuwXJnMlnA0j195hkMfhnxhGkMERa3kXXW6KvR5qt88oSNGvY=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=vitteaymeric@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox