From: Mike Hearn <mike@plan99•net>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY
Date: Sun, 11 Jan 2015 19:56:29 +0100 [thread overview]
Message-ID: <CANEZrP3SE_=w_3K5YK2_L3JpiPp27Ykzbk79vn+3PsUAVWgzYg@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgTMKwo2LOAmW+WzFnHcE7UXvCKgi7WCQLMtGDn2eaxLDA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3648 bytes --]
Firstly, apologies to Nathan for not actually providing feedback on his
protocol. I've put pondering it onto my mental todo list. The notion of a
payment tree is interesting but complicated - I would need to think about
it and maybe draw myself some diagrams before having useful feedback here.
If you wanted to implement it, you could fork the existing code in bitcoinj
and extend it with the new functionality.
I raised the original Satoshi design mainly to inform and so the approaches
can be compared. It may well be that this proposed protocol is superior in
every way, in which case the nSequence approach would be of no further use,
assuming Nathan's protocol generalises to n-party HFT.
Replying now to Gregory:
I think we agree, and are just phrasing things differently (or slowly
groping towards consensus at the speed of email threads :-).
It's likely that over time Bitcoin will end up being multi-layered, with
the block chain being the base layer that syncs everyone up, and higher
layers doing things that miners either can't do or can't be trusted to do.
Like the proposal from GreenAddress to be a well known signer who is
trusted to not double spend.
From miners perspective, there are multiple schemes where they are viable
if cost(fraud) < benefit, at the moment unconfirmed transactions appear to
be an example of that, and putting resource control considerations to one
side, it's possible that tx replacement would be the same. Or not. The
calculation for miners isn't easy, because if they play by the rules then
they may have a long term and reliable income stream, but if they break the
rules then that payment traffic will migrate to other solutions and they
end up with nothing. Whether it's worth it depends on how long term they're
thinking.
If we imagine a hypothetical future where lots of economic activity is
being done over Satoshi-style replaceable contracts, and suddenly a new big
short-termist miner comes along who decides that just breaking the rules
will give him more profit before the business dries up, what would happen?
If fraud costs get too extreme the old fallback of a purely centralised
solution is always there - for software compatibility purposes this would
look like a trusted node who doesn't broadcast the transactions at all and
just keeps them centrally, then mines or broadcasts the final version
themselves. Client apps would just be configured to connect directly to
that node.
Making that more competitive means having more such nodes/miners, until
eventually you have a network of miners that are regulated by identity and
bannable and don't share the tx's outside their network. That probably gets
you 95% of the benefit of the old model with maybe 150% (wild ass guess) of
the costs. "Identity" in this case can mean lots of fancy crypto things
beyond old-fashioned govt name+address style.
I don't think that'd be just an expensive and inefficient PayPal, as you'd
still have the key difference that simplifies so much - the trusted third
party doesn't hold any funds on deposit and can't directly
steal/lend/gamble with any funds. To earn money by being corrupt requires
complicated schemes where they strike secret deals to favour one party or
another, and that corruption can then be easily detected and published, so
it seems like the risk is much lower.
Bitcoin is already a pretty complex ecosystem with different kinds of trust
and decentralisation models in use. I see the next 5-10 years as a giant
cost optimisation experiment .... where are the best settings of the
various decentralisation/speed/fees/complexity/identity knobs for different
kinds of people?
[-- Attachment #2: Type: text/html, Size: 4045 bytes --]
next prev parent reply other threads:[~2015-01-11 18:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-09 11:40 Nathan Cook
2015-01-09 13:20 ` Mike Hearn
2015-01-09 13:22 ` Jeff Garzik
2015-01-09 13:42 ` Mike Hearn
2015-01-09 14:50 ` Gregory Maxwell
2015-01-11 18:56 ` Mike Hearn [this message]
2015-01-11 9:16 ` odinn
2015-01-09 13:26 ` Gregory Maxwell
2015-01-11 22:24 ` Peter Todd
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='CANEZrP3SE_=w_3K5YK2_L3JpiPp27Ykzbk79vn+3PsUAVWgzYg@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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