Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd420-0004i4-Fh for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 20:44:36 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.128.181 as permitted sender) client-ip=209.85.128.181; envelope-from=aritter@gmail.com; helo=mail-ve0-f181.google.com; Received: from mail-ve0-f181.google.com ([209.85.128.181]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd41z-0000jD-DL for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 20:44:36 +0000 Received: by mail-ve0-f181.google.com with SMTP id oy12so1774873veb.40 for ; Wed, 23 Apr 2014 13:44:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.104.33 with SMTP id gb1mr1067754vdb.45.1398285869877; Wed, 23 Apr 2014 13:44:29 -0700 (PDT) Received: by 10.220.140.208 with HTTP; Wed, 23 Apr 2014 13:44:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Apr 2014 22:44:29 +0200 Message-ID: From: Adam Ritter To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1136b5e491918e04f7bbcc8d X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -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 (aritter[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: 1Wd41z-0000jD-DL 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 20:44:36 -0000 --001a1136b5e491918e04f7bbcc8d Content-Type: text/plain; charset=UTF-8 Isn't a faster blockchain for transactions (maybe as a sidechain) solving the problem? If there would be a safe way for 0-confirmation transactions, the Bitcoin blockchain wouldn't even be needed. On Wed, Apr 23, 2014 at 10:37 PM, Mike Hearn wrote: > On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell wrote: > >> Right, this works in the Bitcoin network today absent any collusion by >> the miners. You give one miner a transaction and you give every other >> node you can reach another transaction. >> > > Yes, but that can be fixed with double spend alerts. > > >> Someone you ask to not double spend is an entirely separate matter. >> They aren't self-selecting: you select who you trust to not make >> double spends and there is no need for this trust to be globally >> consistent. >> > > No? It's not just your decision that matters, the receiver also has to > trust them. They're like a dispute mediator in this regard. You can pick > whoever you want, but that doesn't matter if the receiver doesn't recognise > them or trust them. You have to find an overlap to make an instant trade. > > In practice if people have to think about this, evaluate brands etc then > you'd get a very small number of parties because the value of global > agreement is so high. Then it becomes hard to remove ones that have a lot > of momentum. > > The censorship resistance of the block chain doesn't matter if your double > spending partners refuse to help you spend your money (because they're > being coerced). The censorship can just happen at a different place. > > >> To stop GHash.io we would have to take away their hardware or change the >> Bitcoin >> protocol to make their hardware useless >> > > ..... or, have a majority decide to zero out their coinbase rewards for > blocks that double spent against dice sites. That wouldn't undo the double > spend, but you can't do that with the multisig scheme either. All you can > do is punish the corrupted party post-hoc, either by not using them again, > or by "unpaying" them for the service they did not provide. > > > > ------------------------------------------------------------------------------ > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a1136b5e491918e04f7bbcc8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Isn't a faster blockchain for transactions (maybe as a= sidechain) solving the problem? If there would be a safe way for 0-confirm= ation transactions, the Bitcoin blockchain wouldn't even be needed.


On Wed, Apr 2= 3, 2014 at 10:37 PM, Mike Hearn <mike@plan99.net> wrote:
On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell <gmaxwell@g= mail.com> wrote:
Right, this works in the Bitcoin networ= k today absent any collusion by
the miners. You give one miner a transaction and you give every other
node you can reach another transaction.

Yes, but that can be fixed with double spend alerts.
=C2=A0
Someone you ask to not double spend is an entirely separate matter.
They aren't self-selecting: you select who you trust to not make
double spends and there is no need for this trust to be globally
consistent.

No? It's not just= your decision that matters, the receiver also has to trust them. They'= re like a dispute mediator in this regard. You can pick whoever you want, b= ut that doesn't matter if the receiver doesn't recognise them or tr= ust them. You have to find an overlap to make an instant trade.

In practice if people have to think about this, evaluat= e brands etc then you'd get a very small number of parties because the = value of global agreement is so high. Then it becomes hard to remove ones t= hat have a lot of momentum.

The censorship resistance of the block chain doesn'= t matter if your double spending partners refuse to help you spend your mon= ey (because they're being coerced). The censorship can just happen at a= different place.
=C2=A0
To stop GHash.io=C2=A0we wo= uld have to take away their hardware or change the Bitcoin
protocol to make their hardware useless
=C2=A0
..... or, have a majority decide to zero out their coinbase reward= s for blocks that double spent against dice sites. That wouldn't undo t= he double spend, but you can't do that with the multisig scheme either.= All you can do is punish the corrupted party post-hoc, either by not using= them again, or by "unpaying" them for the service they did not p= rovide.


-----------------------------------------------------------------------= -------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.n= et/sfu/ExoPlatform
_______________________________________________ Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a1136b5e491918e04f7bbcc8d--