From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd5Je-0003X8-IA for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 22:06:54 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.44 as permitted sender) client-ip=209.85.192.44; envelope-from=alex.mizrahi@gmail.com; helo=mail-qg0-f44.google.com; Received: from mail-qg0-f44.google.com ([209.85.192.44]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd5Jd-0008Pg-Og for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 22:06:54 +0000 Received: by mail-qg0-f44.google.com with SMTP id q108so1648733qgd.17 for ; Wed, 23 Apr 2014 15:06:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.163.73 with SMTP id z9mr25155220qax.90.1398290808238; Wed, 23 Apr 2014 15:06:48 -0700 (PDT) Received: by 10.96.77.38 with HTTP; Wed, 23 Apr 2014 15:06:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 01:06:48 +0300 Message-ID: From: Alex Mizrahi To: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e0158b030eaf63504f7bcf271 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.192.44 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (alex.mizrahi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Wd5Jd-0008Pg-Og Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 22:06:54 -0000 --089e0158b030eaf63504f7bcf271 Content-Type: text/plain; charset=UTF-8 > > These sorts of proposals are all just ways of saying block chains kind of > suck and we should go back to using trusted third parties. > No. Different approaches have different trade-offs, and thus different areas of applicability. Proof-of-work's inherent disadvantage is that it takes some time until transaction becomes practically irreversible. On the other hand, it has advantages like neutrality, censorship-resistance, high degree of security, etc. TTP can be very efficient, but doesn't have advantages mentioned above. It is possible to combine several different approaches into one hybrid systems. For example, classic Bitcoin PoW blockchain can be used for settlements, large transactions, savings and so on. While TTP-based payment system will be used for small-value transaction like buying coffee. In this case you get benefits of both approaches. Censorship-resistance is irrelevant when one buys a cup of coffee with his pocket money, isn't it? For some reason, instead of considering these hybrid solutions (which can also address scalability problems), you want to make PoW-based system more complex to be applicable for real-time transaction too. This will, likely, weaken advantages provided by PoW, and also it won't provide any hard guarantees, and, if implemented, will undermine development of alternative solutions. --089e0158b030eaf63504f7bcf271 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
These sorts of proposals are all just ways of saying block chains kind= of suck and we should go back to using trusted third parties.=C2=A0
<= /div>

No.
Different a= pproaches have different trade-offs, and thus different areas of applicabil= ity.

Proof-of-work's inherent disadvantage is that= it takes some time until transaction becomes practically irreversible. On = the other hand, it has advantages like neutrality, censorship-resistance, h= igh degree of security, etc.

TTP can be very efficient, but doesn't have advanta= ges mentioned above.

It is possible to combine sev= eral different approaches into one hybrid systems. For example, classic Bit= coin PoW blockchain can be used for settlements, large transactions, saving= s and so on. While TTP-based payment system will be used for small-value tr= ansaction like buying coffee.

In this case you get benefits of both approaches. Censo= rship-resistance is irrelevant when one buys a cup of coffee with his pocke= t money, isn't it?

For some reason, instead of= considering these hybrid solutions (which can also address scalability pro= blems), you want to make PoW-based system more complex to be applicable for= real-time transaction too.

This will, likely, weaken advantages provided by PoW, a= nd also it won't provide any hard guarantees, and, if implemented, will= undermine development of alternative solutions.

--089e0158b030eaf63504f7bcf271--