[Bitcoin-development] Some PR preparation

[Bitcoin-development] Some PR preparation

[Alan Reiner]

I'm sure it won't be long before Slashdot and a variety of sources start
reporting on this event.  Bitcoin has been in the media a lot lately, so
this story is likely to get some attention.  The blowback of this event
is mostly psychological, so I think it would be exceptionally wise to
start preparing PR comments that can be posted on articles immediately
after they go public.  This event is likely draw much more negative
attention than it deserves, and getting some positive&informed comments
posted up front will potentially make a difference in the way the story
is received. 

Undoubtedly, many articles (and especially commenters) will shape this
into "the end of Bitcoin".   I would describe it as "there was a short
and mostly-harmless lapse in the ability of the network to reach a
consensus, causing transactions to get delayed by a few hours."   It
*really* needs to be emphasized that coins are safe, and nothing anyone
has/could do will change that.  And that it would've been extremely
difficult to exploit for gain.  Transactions got delayed while a bug was
fixed.  End of story.

Hell, someone here should submit their own slashdot article about it! 
100% chance this hits slashdot -- it might as well be written by someone
who understands it.  Similarly, we could be sending sources information
to pre-empt misinformation being spread about it.  Unfortunately, I have
to go to bed, so I can't really do much.  I just wanted folks to be on
the lookout and be ready to respond to the crazy stuff that's going to
hit the media in the next 12 hours.

-Alan

Re: [Bitcoin-development] Some PR preparation

[Luke-Jr]

On Tuesday, March 12, 2013 7:03:54 AM Alan Reiner wrote:
> I'm sure it won't be long before Slashdot and a variety of sources start
> reporting on this event.  Bitcoin has been in the media a lot lately, so
> this story is likely to get some attention.  The blowback of this event
> is mostly psychological, so I think it would be exceptionally wise to
> start preparing PR comments that can be posted on articles immediately
> after they go public.  This event is likely draw much more negative
> attention than it deserves, and getting some positive&informed comments
> posted up front will potentially make a difference in the way the story
> is received.
> 
> Undoubtedly, many articles (and especially commenters) will shape this
> into "the end of Bitcoin".   I would describe it as "there was a short
> and mostly-harmless lapse in the ability of the network to reach a
> consensus, causing transactions to get delayed by a few hours."   It
> *really* needs to be emphasized that coins are safe, and nothing anyone
> has/could do will change that.  And that it would've been extremely
> difficult to exploit for gain.  Transactions got delayed while a bug was
> fixed.  End of story.

I think we should be careful not to downplay the reality either.
For a number of hours, transactions could have received up to N confirmations 
and then still been reversed. While we could contact the bigger payment 
processors, I saw people still trying to buy/sell on OTC, whom could have been 
scammed even by taking standard precautions.

Luke

Re: [Bitcoin-development] Some PR preparation

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr <luke@dashjr.org> wrote:

>
>
> I think we should be careful not to downplay the reality either.
> For a number of hours, transactions could have received up to N
> confirmations
> and then still been reversed. While we could contact the bigger payment
> processors, I saw people still trying to buy/sell on OTC, whom could have
> been
> scammed even by taking standard precautions.
>
>
I don't want to misrepresent what happened, but how much of that was really
a risk?  The block was rejected, but the transactions were not.  Any valid
transactions to hit the network would get added to everyone's memory pool
and mined in both chains.  Thus all nodes would still reject double-spend
attempts.  As far as I understood it, you would've had to have majority
mining power on one of the chains (and both had non-negligible computing
power on them), so double-spending still required an exceptional amount of
resources -- just not the normal 50% that is normally needed.  Perhaps...
10%?   But how many people can even have 10%?  In addition to that, a
victim needs to be found that hasn't seen the alert, is willing to execute
a large transaction, and is on the wrong side of the chain.

Is this incorrect?  Yes, there was less resources needed to execute an
attack -- but it still required a very powerful attacker, way outside the
scope of "regular users."

[-- Attachment #2: Type: text/html, Size: 2018 bytes --]

Re: [Bitcoin-development] Some PR preparation

[Peter Vessenes]

[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]

Can some enterprising soul determine if there were any double-spend
attempts?

I'm assuming no, and if that's the case, we should talk about that publicly.

Either way, I think it's generally another test well done by everyone;
people pitched in on PR, tech, communication, yay Bitcoin!



On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner <etotheipi@gmail.com> wrote:

> On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr <luke@dashjr.org> wrote:
>
>>
>>
>> I think we should be careful not to downplay the reality either.
>> For a number of hours, transactions could have received up to N
>> confirmations
>> and then still been reversed. While we could contact the bigger payment
>> processors, I saw people still trying to buy/sell on OTC, whom could have
>> been
>> scammed even by taking standard precautions.
>>
>>
> I don't want to misrepresent what happened, but how much of that was
> really a risk?  The block was rejected, but the transactions were not.  Any
> valid transactions to hit the network would get added to everyone's memory
> pool and mined in both chains.  Thus all nodes would still reject
> double-spend attempts.  As far as I understood it, you would've had to have
> majority mining power on one of the chains (and both had non-negligible
> computing power on them), so double-spending still required an exceptional
> amount of resources -- just not the normal 50% that is normally needed.
>  Perhaps... 10%?   But how many people can even have 10%?  In addition to
> that, a victim needs to be found that hasn't seen the alert, is willing to
> execute a large transaction, and is on the wrong side of the chain.
>
> Is this incorrect?  Yes, there was less resources needed to execute an
> attack -- but it still required a very powerful attacker, way outside the
> scope of "regular users."
>
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
------------------------------

[image: CoinLab Logo]PETER VESSENES
CEO

*peter@coinlab.com * /  206.486.6856  / SKYPE: vessenes
811 FIRST AVENUE  /  SUITE 480  /  SEATTLE, WA 98104

[-- Attachment #2: Type: text/html, Size: 4729 bytes --]

Re: [Bitcoin-development] Some PR preparation

[Gregory Maxwell]

On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner <etotheipi@gmail.com> wrote:
> I don't want to misrepresent what happened, but how much of that was really
> a risk?  The block was rejected, but the transactions were not.

Some but not much.  If someone flooded a bunch of duplicate
concurrently announcing both spends to as many nodes as they could
reach they would almost certainly gotten some conflicts into both
chains. Then both chains would have gotten >6 confirms. Then one chain
would pop and anyone on the popped side would see >6 confirm
transactions undo.

This attack would not require any particular resources, and only
enough technical sophistication to run something like pynode to give
raw txn to nodes at random.

The biggest barriers against it were people being uninterested in
attacking (as usual for all things) and there not being many (any?)
good targets who hadn't shut down their deposits.  They would have to
have accepted deposits with <12 confirms and let you withdraw. During
the event an attacker could have gotten  of their deposit-able funds.

On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes <peter@coinlab.com> wrote:
> Can some enterprising soul determine if there were any double-spend attempts?
> I'm assuming no, and if that's the case, we should talk about that publicly.

There were circulating double-spends during the fork (as were visible
on blockchain.info). I don't know if any conflicts made it into the
losing chain, however. It's not too hard to check to see what inputs
were consumed in the losing fork and see if any have been consumed by
different transactions now.

I agree it would be good to confirm no one was ripped off, even though
we can't say there weren't any attempts.

Re: [Bitcoin-development] Some PR preparation

[Gregory Maxwell]

On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes <peter@coinlab.com> wrote:
>> Can some enterprising soul determine if there were any double-spend attempts?
>> I'm assuming no, and if that's the case, we should talk about that publicly.
[snip]
> I agree it would be good to confirm no one was ripped off, even though
> we can't say there weren't any attempts.

https://bitcointalk.org/index.php?topic=152348.msg1616747#msg1616747

Re: [Bitcoin-development] Some PR preparation

[Christian Decker]

Just a quick and dirty check if something bad actually happened. 430
transactions that were confirmed in the alt-chain, are not confirmed
in the true blockchain. The good news is that as far as I can tell
most of them are low volume transactions destined for SD.

7 transactions were true double spends, or to be more precise
transactions in which an conflicting transaction was confirmed in the
new chain (with their respective amount):

12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195 261 BTC
cb36ba33b3ecd4d3177d786209670c9e6cdf95eb62be54986f0b49ca292714af 0.06 BTC
7192807f952b252081d0db0aa7575c4695b945820adaf7776b7189e6b3d86f96 0.01 BTC
355d4ea51c3b780cf0b10e8099a06a31484e0060bc140b63f3d6e5fb713ace5e 0.05 BTC
b961bc0c663a46893afd3166a604e7e2639533522d9fec61fdb95eb665e86f5a 0.61 BTC
138063e4bdb76feaa511f1e7f9c681eb468ef9140c141671741c965e503b84c6 1.62 BTC
a10bd194cdbf9aa4c12eb0b120056998a081a9b0d93d70570edff24dec831f90 0.81

So the one transaction that really hurt was the one published on
BitcoinTalk. We're not yet out of the woods as some of the 423
transactions still have a chance of being doublespent, but looks like
it's not that bad after all.

Cheers,
Chris

P.S.: For a complete list of transactions see http://pastebin.com/wctJU3Ln
--
Christian Decker


On Tue, Mar 12, 2013 at 7:39 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
>> On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes <peter@coinlab.com> wrote:
>>> Can some enterprising soul determine if there were any double-spend attempts?
>>> I'm assuming no, and if that's the case, we should talk about that publicly.
> [snip]
>> I agree it would be good to confirm no one was ripped off, even though
>> we can't say there weren't any attempts.
>
> https://bitcointalk.org/index.php?topic=152348.msg1616747#msg1616747
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Some PR preparation

[Peter Vessenes]

[-- Attachment #1: Type: text/plain, Size: 3673 bytes --]

Thanks Chris.

Yep, looks like an honest-ish user managed to accidentally get one tx into
one chain and another into the other.

I think I'd cautiously say that if OKPay gets their cash back, or freezes
his balance nobody is out BTC for last night, (instead just time and
effort).

I'm doing a little FUD-fighting right now, but will try and pick up a bit
more if necessary tonight after my flight lands. I think this is mostly
over the heads of a lot of our typical media contacts, though.

Peter


On Tue, Mar 12, 2013 at 12:53 PM, Christian Decker <
decker.christian@gmail.com> wrote:

> Just a quick and dirty check if something bad actually happened. 430
> transactions that were confirmed in the alt-chain, are not confirmed
> in the true blockchain. The good news is that as far as I can tell
> most of them are low volume transactions destined for SD.
>
> 7 transactions were true double spends, or to be more precise
> transactions in which an conflicting transaction was confirmed in the
> new chain (with their respective amount):
>
> 12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195 261 BTC
> cb36ba33b3ecd4d3177d786209670c9e6cdf95eb62be54986f0b49ca292714af 0.06 BTC
> 7192807f952b252081d0db0aa7575c4695b945820adaf7776b7189e6b3d86f96 0.01 BTC
> 355d4ea51c3b780cf0b10e8099a06a31484e0060bc140b63f3d6e5fb713ace5e 0.05 BTC
> b961bc0c663a46893afd3166a604e7e2639533522d9fec61fdb95eb665e86f5a 0.61 BTC
> 138063e4bdb76feaa511f1e7f9c681eb468ef9140c141671741c965e503b84c6 1.62 BTC
> a10bd194cdbf9aa4c12eb0b120056998a081a9b0d93d70570edff24dec831f90 0.81
>
> So the one transaction that really hurt was the one published on
> BitcoinTalk. We're not yet out of the woods as some of the 423
> transactions still have a chance of being doublespent, but looks like
> it's not that bad after all.
>
> Cheers,
> Chris
>
> P.S.: For a complete list of transactions see http://pastebin.com/wctJU3Ln
> --
> Christian Decker
>
>
> On Tue, Mar 12, 2013 at 7:39 PM, Gregory Maxwell <gmaxwell@gmail.com>
> wrote:
> > On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell <gmaxwell@gmail.com>
> wrote:
> >> On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes <peter@coinlab.com>
> wrote:
> >>> Can some enterprising soul determine if there were any double-spend
> attempts?
> >>> I'm assuming no, and if that's the case, we should talk about that
> publicly.
> > [snip]
> >> I agree it would be good to confirm no one was ripped off, even though
> >> we can't say there weren't any attempts.
> >
> > https://bitcointalk.org/index.php?topic=152348.msg1616747#msg1616747
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_d2d_mar
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
------------------------------

[image: CoinLab Logo]PETER VESSENES
CEO

*peter@coinlab.com * /  206.486.6856  / SKYPE: vessenes
811 FIRST AVENUE  /  SUITE 480  /  SEATTLE, WA 98104

[-- Attachment #2: Type: text/html, Size: 6131 bytes --]