[Bitcoin-ml] Bitcoin Cash Roadmap

G. Andrew Stone g.andrew.stone at gmail.com
Thu Aug 10 15:42:41 UTC 2017


Oh ok I understand.  The question that you are really asking is whether
smart contracts are viable AT ALL.  Why not use an escrow service,
implemented as an n-of-m multisig?

It is a good point, and I think there was a great talk about that at the
future of bitcoin conference.  I briefly addressed that in my document, but
that more philosophic question is beyond its scope.

However, from a practical and legal perspective, its a LOT simpler and
easier for an entity to simply offer a service that makes signed statements
about world events than to be a signing authority over money and retain a
dispute resolution staff capable of handling arbitrary agreements.  This
means the escrow service will charge higher fees.

Sufficiently complex contracts will need escrow, but simple contracts can
be done on the blockchain with "smart contracts".  We cannot know today
where the boundary is.

But in the crypto-is-successful future you might even imagine that the
middleman oracle gets cut out -- the source of the event could publish the
signed statement for quantitative events like closing stock prices, sports
scores, etc.


Now let's back up a second and consider what you are doing.  You are
basically saying "to deploy this service, you must convince ME that its
worthwhile".  This is how innovation dies, and why there is no on-chain
innovation going on in Bitcoin -- you have to convince the Core group its
worthwhile, and the xthin effort showed how impossible that is.

Any student of history knows that innovation must be as permissionless as
possible to succeed.

Right now, this is not possible because the scripting language was
hamstrung.  To activate innovation, we need to make the scripting language
more powerful.  To do that, we need to deny potential opcodes on the basis
of security, efficiency, or lack of generality -- not because we personally
don't believe in a particular use case.

The opcode I am suggesting is very general.  It allows a script to validate
arbitrary signed data that can then be used for any purpose.  It is
arguably more generally applicable than the current CHECKSIG opcode.  I may
suggest only one purpose, but your opinion of the popularity of that one
should not have significant influence on admitting the opcode or not.




On Thu, Aug 10, 2017 at 10:36 AM, Tom Zander via bitcoin-ml <
bitcoin-ml at lists.linuxfoundation.org> wrote:

> On Thursday, 10 August 2017 16:20:00 CEST G. Andrew Stone wrote:
> > I included this section because I think that is the way most people
> > imagine it would/should be done, but I then move on to the idea of having
> > the oracle's data embedded directly in the transaction.
>
> like a 3rd party that could provide a signature in an 2-out-of-3 multisig
> standard dispute resolution scenario?
>
> > This is not meant to be a primer on the subject of smart contracts.  I do
> > expect that the reader is familiar with the problems associated with
> smart
> > contracts and therefore related concepts like oracles, although I do have
> > a 1-liner definition for those who need reminding.
> >
> > I do expect to be able to use a term like "binary options" and have the
> > reader instantly see the use case rather than spending valuable minutes
> of
> > people's attention with a full fledged scenario-based description.
>
> I still dont see what the benefit is over n-of-m multisig. Your terminology
> is extremely broadly applicable and certainly does not bring a usecase to
> mind. If you are not willing to explain your reasons for doing it different
> then don’t be surprised that the ideas are hard to sell.
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170810/606c9e16/attachment.html>


More information about the bitcoin-ml mailing list