public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Caleb James DeLisle <calebdelisle@lavabit.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
Date: Wed, 15 May 2013 08:40:59 -0400	[thread overview]
Message-ID: <5193825B.20909@lavabit.com> (raw)
In-Reply-To: <20130515114956.GA5863@netbook.cypherspace.org>

I can't see this working, if 51% of the mining power doesn't like your
coins, when you create the commitment they will reject it.
If the commitment is opaque at the time of inclusion in the block then
I will create multiple commitments and then after revealing the
commitment and spend to you I will reveal the earlier commitment which
commits the coins to an address I control.

On the topic of reversibility, I suspect in the long term the lack of
chargebacks will create issues as criminals learn that for the first
time in history, kidnap & ransom is effective. Suffice to say after the
first >= $10mn kidnapping-for-bitcoin heist, governments will be forced
to decide how they view the system. It will likely fall somewhere between
"arrest/question anyone identified holding tainted coins" to something
nonsensical and reactionary like "blocking" bitcoin as Iran does TOR.

Thanks,
Caleb



On 05/15/2013 07:49 AM, Adam Back wrote:
> On Wed, May 15, 2013 at 07:19:06AM -0400, Peter Todd wrote:
>> Protocols aren't set in stone - any attacker that controls enough
>> hashing power to pose a 51% attack can simply demand that you use a
>> Bitcoin client modified [to facilitate evaluation of his policy]
> 
> Protocol voting is a vote per user policy preference, not a CPU vote, which
> is the point.  Current bitcoin protocol is vulnerable to hard to prove
> arbitrary policies being imposable by a quorum of > 50% miners.  The blind
> commitment proposal fixes that, so even an 99% quorum cant easily impose
> policies, which leaves the weaker protocol vote attack as the remaining
> avenue of attack.  That is a significant qualitative improvement.
> 
> The feasibility of protocol voting attacks is an open question, but you
> might want to consider the seeming unstoppability of p2p protocols for a
> hint.
> 
> Adam
> 
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 




  reply	other threads:[~2013-05-15 12:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-14 11:51 [Bitcoin-development] ecash and revocability Adam Back
2013-05-14 14:09 ` [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability) Adam Back
2013-05-14 14:27   ` Simon Barber
2013-05-14 17:30   ` grarpamp
2013-05-15 10:25   ` [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability) Adam Back
2013-05-15 11:19     ` Peter Todd
2013-05-15 11:49       ` Adam Back
2013-05-15 12:40         ` Caleb James DeLisle [this message]
2013-05-15 16:21           ` Adam Back
2013-05-15 18:01             ` Caleb James DeLisle
2013-05-15 23:40             ` Adam Back
2013-05-16  1:24               ` Gavin
2013-05-16  1:39                 ` Gregory Maxwell
2013-05-16  2:22                   ` Mike Hearn
2013-05-16  2:45                     ` Gregory Maxwell
2013-05-16  5:52                       ` Caleb James DeLisle
2013-05-16 11:32                       ` Adam Back
2013-05-16 14:51                         ` Adam Back

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=5193825B.20909@lavabit.com \
    --to=calebdelisle@lavabit.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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