Re: [Bitcoin-development] Another uninitialized memory problem

2014-06-03 Thread Wladimir 
On Mon, Jun 2, 2014 at 10:01 PM, Toshi Morita  wrote:
> I'm seeing another uninitialized memory problem in bitcoind using valgrind:

Thanks for the report.

Which version/commit id of bitcoind?

Wladimir

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Lets discuss what to do if SHA256d is actually broken

2014-06-03 Thread Ethan Heilman 
An attack on the mining difficulty algorithm does not imply violation of
the typical security properties of a cryptographic hash function*.

Assume someone discovers a method which makes it far easier to discover new
blocks, this method: may or may not be implementable by the current SHA256
ASIC hardware.

1. If it is usable by the mining hardware, then there will be brief period
of overproduction and then difficulty will adjust. If the attack is so bad
that difficulty can't scale and we run out of a leading zero's, then the
SHA256 collision resistance is broken and we have bigger problems. Under
this scenario, everyone would see the need to immediately switch to new
hardware as people could create cycles and irreconcilable forks in the
block chain

2. If the attack is not usable by the mining hardware, then the miners will
need to switch to new ASICs anyways and the hash function can be changed
without resistance.

But lets ignore all that and say, for some unspecified reason, the bitcoin
community wants to switch hash functions and has some lead time to do so.
One could require that miners find two blocks, one computed using SHA256
and one computed using the new hash function. We could then slowly shift
the difficulty from SHA256 to the new hash function. This would allow
miners a semi-predicable roadmap to switch their infrastructure away from
SHA256.

* It would be a distinguisher which would be bad, but collision resistance
could be merely weakened.


On Tue, Jun 3, 2014 at 12:52 AM, Luke Dashjr  wrote:

> On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
> > Hi,
> >
> > I thought a lot about the worst case scenario of SHA256d being broken in
> a
> > way which could be abused to
> > A) reduce the work of mining a block by some significant amount
> > B) reduce the work of mining a block to zero, i.e. allow instant mining.
>
> C) fabricate past blocks entirely.
>
> If SHA256d is broken, Bitcoin as it is fails entirely.
>
> Luke
>
>
> --
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Lets discuss what to do if SHA256d is actually broken

2014-06-03 Thread Kevin 
On 6/3/2014 12:29 AM, xor wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> I thought a lot about the worst case scenario of SHA256d being broken in a way
> which could be abused to
> A) reduce the work of mining a block by some significant amount
> B) reduce the work of mining a block to zero, i.e. allow instant mining.
>
> Bitcoin needs to be prepared for this as any hash function has a limited
> lifetime. Usually crypto stuff is not completely broken instantly by new
> attacks but gradually. For example first the attack difficulty is reduced from
> 2^128 to 2^100, then 2^64, etc.
> This would make scenario A more likely.
>
> Now while B sounds more dangerous, I think in fact A is:
> Consider how A would happen in real life: Someone publishes a paper of a
> theoretical reduction of SHA256d attacks to 2^96 bit. Mathematicians will
> consider this as a serious attack and create a lot of riot.
> If no plan is made early enough, as in now, the Bitcoin Core team might then
> probably want to just do the easiest approach of replacing the hash function
> after a certain block number, i.e. a hard fork.
> But what about the Bitcoin miners, those who need to actually accept a change
> of mining algorithm which renders their hardware which cost MILLIONS
> completely worthless?
> Over the years they have gotten used to exponential growth of the Bitcoin
> networks hashrate, and therefore exponential devaluation of their mining
> hardware. Even if the attack on SHA256d causes a significant growth of
> difficulty, the miners will not *believe* that it is an actual attack on 
> SHA256d
> - - maybe it is just some new large mining operation?  They are used to this
> happening! Why should they believe this and switch to a new hash function
> which requires completely new hardware and therefore costs them millions?
> They will just keep mining SHA256d. Thats why this is more dangerous, because
> changing the hash funciton won't be accepted by the miners even though it is
> broken.
> Something smarter needs to be thought of.
>
> Now I must admit that I am not good at cryptography at all, but I had the
> following idea: Use the altcoin concept of having multiple hash functions in a
> chain. If SHA256d is broken, it is chained with a new hash function.
> Thereby, people who want to mine the new replacement hash function still will
> need ASICs which can solve the old SHA proof of work. So existing ASIC owners
> can amend their code to do SHA256d using the ASIC, and then the second hash
> function using a general purpose CPU.
> This would also allow a smooth migration of difficulty - I don't even know how
> difficulty would react with the naive approach of just replacing SHA with
> something else: It would probably be an unsolvable problem to define new rules
> to make it decrease enough so new blocks can actually be mined by the now
> several orders of magnitude slower CPU-only mining community but still be high
> enough to be able to deal with the fact that millions of people will try their
> luck with mining at the release date.
>
> While this sounds simple in theory, it might be a lot of work to implement, so
> you guys might want to take precautions for it soon :)
>
> Greetings,
>   xor - A Freenet project developer
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQIcBAEBCAAGBQJTjU9DAAoJEMtmZ+8tjWt5pNEP/2460eHu7ujrUSxinJXY7+wF
> E759/NcpNuakqu4NsS3ndi8lSiVIeixiOWZxPwLYkzC0pgPd5JrK5hdrYewsgreL
> Ltkh6LKB4YZLYrV3jm62ZPMTzCopYQ1l872xbN3PJQJoXhEp4fKu99++LDzVg9Gk
> n7rvrk6Iy/nSsZ1IMANpKghbU8/Gtn6ppCJv9rxRE//CZdTso1tTyOXXkEEMTHcV
> y/iv6CHXtTXPvOgEgciU0oCPq0NOUKdIAOD//ybcKzncOoHSmwr1rZdreCTH6/Ek
> 9uwq/HaQnseHPrq9qrIkIKrZDlnjKu7Tqw1BlbyBeCrWdJPCeDJg2kyCXgTvIzFD
> oXwZ6r16tb2QPR4ByyO1lZy9G2Pp26thk12BnadnPYTf1rMvsY15BjfUrCU9ppt/
> YpFAZSFlXUGOuOBKUznUeO8U1bXJylcTTnyER/cudOpcKR8Jt9l5tfm5LTHCB6Q2
> Tjmvsmd0BzwafLEhHD5FHoTZFNVdXWvEUO/w4I/2UWTS7CacbE1qk0rVpsF/4L1K
> /oFVnZIUKqsm5mMMb6WTQq+MjP2TF/eAAwm2UtFYmj0FVML9HBNwyiAc5UKwnD4Y
> Yq3Pl5QfRobwu6pgT3zO7vK+saOl8sePWbU8Skj41OTEDrJM4QIQGAqs1U8xke8+
> YnUYiyzreJ8ofHhNBs4/
> =dkuk
> -END PGP SIGNATURE-
>
>
> --
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
It is good to start thinking about such things.  Let's face it, it could 
happen.  However, short of having bitcoin use another algorithm for 
encryption, I am not sure much could be done.  That's just me.


-- 
Kevin


--

Re: [Bitcoin-development] Lets discuss what to do if SHA256d is actually broken

2014-06-03 Thread Ashley Holman 
There is a relevant post from Satoshi on this:

https://bitcointalk.org/index.php?topic=191.msg1585#msg1585

Quote:

"If SHA-256 became completely broken, I think we could come to some
agreement about what the honest block chain was before the trouble started,
lock that in and continue from there with a new hash function.

If the hash breakdown came gradually, we could transition to a new hash in
an orderly way.  The software would be programmed to start using a new hash
after a certain block number.  Everyone would have to upgrade by that time.
 The software could save the new hash of all the old blocks to make sure a
different block with the same old hash can't be used."


On Tue, Jun 3, 2014 at 9:21 PM, Ethan Heilman  wrote:

> An attack on the mining difficulty algorithm does not imply violation of
> the typical security properties of a cryptographic hash function*.
>
> Assume someone discovers a method which makes it far easier to discover
> new blocks, this method: may or may not be implementable by the current
> SHA256 ASIC hardware.
>
> 1. If it is usable by the mining hardware, then there will be brief period
> of overproduction and then difficulty will adjust. If the attack is so bad
> that difficulty can't scale and we run out of a leading zero's, then the
> SHA256 collision resistance is broken and we have bigger problems. Under
> this scenario, everyone would see the need to immediately switch to new
> hardware as people could create cycles and irreconcilable forks in the
> block chain
>
> 2. If the attack is not usable by the mining hardware, then the miners
> will need to switch to new ASICs anyways and the hash function can be
> changed without resistance.
>
> But lets ignore all that and say, for some unspecified reason, the bitcoin
> community wants to switch hash functions and has some lead time to do so.
> One could require that miners find two blocks, one computed using SHA256
> and one computed using the new hash function. We could then slowly shift
> the difficulty from SHA256 to the new hash function. This would allow
> miners a semi-predicable roadmap to switch their infrastructure away from
> SHA256.
>
> * It would be a distinguisher which would be bad, but collision resistance
> could be merely weakened.
>
>
> On Tue, Jun 3, 2014 at 12:52 AM, Luke Dashjr  wrote:
>
>> On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
>> > Hi,
>> >
>> > I thought a lot about the worst case scenario of SHA256d being broken
>> in a
>> > way which could be abused to
>> > A) reduce the work of mining a block by some significant amount
>> > B) reduce the work of mining a block to zero, i.e. allow instant mining.
>>
>> C) fabricate past blocks entirely.
>>
>> If SHA256d is broken, Bitcoin as it is fails entirely.
>>
>> Luke
>>
>>
>> --
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Another uninitialized memory problem

2014-06-03 Thread Jeff Garzik 
I think I see the problem.


On Mon, Jun 2, 2014 at 4:01 PM, Toshi Morita  wrote:
> I'm seeing another uninitialized memory problem in bitcoind using valgrind:
>
> tm@tm-VirtualBox:~/bitcoind/bitcoin/src$ valgrind ./bitcoind
> ==2337== Memcheck, a memory error detector
> ==2337== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==2337== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==2337== Command: ./bitcoind
> ==2337==
> ==2337== Conditional jump or move depends on uninitialised value(s)
> ==2337==at 0x319176: CWallet::LoadKeyMetadata(CPubKey const&,
> CKeyMetadata const&) (wallet.cpp:110)
> ==2337==by 0x33645A: ReadKeyValue(CWallet*, CDataStream&, CDataStream&,
> CWalletScanState&, std::string&, std::string&) (walletdb.cpp:509)
> ==2337==by 0x3374F0: CWalletDB::LoadWallet(CWallet*) (walletdb.cpp:623)
> ==2337==by 0x3218FD: CWallet::LoadWallet(bool&) (wallet.cpp:1485)
> ==2337==by 0x157F16: AppInit2(boost::thread_group&) (init.cpp:958)
> ==2337==by 0x140142: AppInit(int, char**) (bitcoind.cpp:143)
> ==2337==by 0x13649E: main (bitcoind.cpp:180)
> ==2337==
>
>
> --
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Another uninitialized memory problem

2014-06-03 Thread Toshi Morita 
I looked at this a bit more yesterday, and it looks like both sides of the
comparison were uninitialized, and I fixed one side, but the other side has
the same problem.

I'll try to investigate further this afternoon once I get out of
meetings/meetings prep.

Toshi



On Tue, Jun 3, 2014 at 9:43 AM, Jeff Garzik  wrote:

> I think I see the problem.
>
>
> On Mon, Jun 2, 2014 at 4:01 PM, Toshi Morita  wrote:
> > I'm seeing another uninitialized memory problem in bitcoind using
> valgrind:
> >
> > tm@tm-VirtualBox:~/bitcoind/bitcoin/src$ valgrind ./bitcoind
> > ==2337== Memcheck, a memory error detector
> > ==2337== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> > ==2337== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright
> info
> > ==2337== Command: ./bitcoind
> > ==2337==
> > ==2337== Conditional jump or move depends on uninitialised value(s)
> > ==2337==at 0x319176: CWallet::LoadKeyMetadata(CPubKey const&,
> > CKeyMetadata const&) (wallet.cpp:110)
> > ==2337==by 0x33645A: ReadKeyValue(CWallet*, CDataStream&,
> CDataStream&,
> > CWalletScanState&, std::string&, std::string&) (walletdb.cpp:509)
> > ==2337==by 0x3374F0: CWalletDB::LoadWallet(CWallet*)
> (walletdb.cpp:623)
> > ==2337==by 0x3218FD: CWallet::LoadWallet(bool&) (wallet.cpp:1485)
> > ==2337==by 0x157F16: AppInit2(boost::thread_group&) (init.cpp:958)
> > ==2337==by 0x140142: AppInit(int, char**) (bitcoind.cpp:143)
> > ==2337==by 0x13649E: main (bitcoind.cpp:180)
> > ==2337==
> >
> >
> >
> --
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/NeoTech
> > ___
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/
>
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Another uninitialized memory problem

2014-06-03 Thread Jeff Garzik 
Does this fix it?  https://github.com/bitcoin/bitcoin/pull/4282


On Tue, Jun 3, 2014 at 12:47 PM, Toshi Morita  wrote:
> I looked at this a bit more yesterday, and it looks like both sides of the
> comparison were uninitialized, and I fixed one side, but the other side has
> the same problem.
>
> I'll try to investigate further this afternoon once I get out of
> meetings/meetings prep.
>
> Toshi
>
>
>
> On Tue, Jun 3, 2014 at 9:43 AM, Jeff Garzik  wrote:
>>
>> I think I see the problem.
>>
>>
>> On Mon, Jun 2, 2014 at 4:01 PM, Toshi Morita  wrote:
>> > I'm seeing another uninitialized memory problem in bitcoind using
>> > valgrind:
>> >
>> > tm@tm-VirtualBox:~/bitcoind/bitcoin/src$ valgrind ./bitcoind
>> > ==2337== Memcheck, a memory error detector
>> > ==2337== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
>> > ==2337== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright
>> > info
>> > ==2337== Command: ./bitcoind
>> > ==2337==
>> > ==2337== Conditional jump or move depends on uninitialised value(s)
>> > ==2337==at 0x319176: CWallet::LoadKeyMetadata(CPubKey const&,
>> > CKeyMetadata const&) (wallet.cpp:110)
>> > ==2337==by 0x33645A: ReadKeyValue(CWallet*, CDataStream&,
>> > CDataStream&,
>> > CWalletScanState&, std::string&, std::string&) (walletdb.cpp:509)
>> > ==2337==by 0x3374F0: CWalletDB::LoadWallet(CWallet*)
>> > (walletdb.cpp:623)
>> > ==2337==by 0x3218FD: CWallet::LoadWallet(bool&) (wallet.cpp:1485)
>> > ==2337==by 0x157F16: AppInit2(boost::thread_group&) (init.cpp:958)
>> > ==2337==by 0x140142: AppInit(int, char**) (bitcoind.cpp:143)
>> > ==2337==by 0x13649E: main (bitcoind.cpp:180)
>> > ==2337==
>> >
>> >
>> >
>> > --
>> > Learn Graph Databases - Download FREE O'Reilly Book
>> > "Graph Databases" is the definitive new guide to graph databases and
>> > their
>> > applications. Written by three acclaimed leaders in the field,
>> > this first edition is now available. Download your free book today!
>> > http://p.sf.net/sfu/NeoTech
>> > ___
>> > Bitcoin-development mailing list
>> > Bitcoin-development@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>>
>>
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc.  https://bitpay.com/
>
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] # error "Bitcoin cannot be compiled without assertions." <<<

2014-06-03 Thread Ron 
Hello

What is the issue with the Bitcoin code for 0.9.x with regard to assertions 
that isn't in 0.8.6 or previous releases?

on April 18th, I offered 

https://github.com/bc4-old-c-coder/bitcoin/commit/f0d221e56a12947b67b9c8f43cc5832b665052c8
 

this commit and code with all side effects removed from the assertions.


Then on the 28th,

https://github.com/bc4-old-c-coder/bitcoin/tree/0.8.6 

this code with unit tests working.

And if that isn't enough, I did a video series on building Bitcoind.exe and the 
static libraries (on MSVC++) all in NDEBUG (release) mode.

See
https://www.youtube.com/playlist?list=PLFnWb0ttBBMLyUuniLp3PJ5Mn4tVUlliZ  
Notice that the NDEBUG release mode is featured, and I even run it!

Lastly what does that say about building Bitcoin-qt in release mode?  Should 
one or not??

There is also a video on building an alternate coin-qt.exe in release mode (gcc 
version) and running it!  See 
https://www.youtube.com/watch?v=C8GvHpjbAnM 


 


assert() should have no side effects, that is the problem.

See
http://books.google.com/books?id=L5ZbzVnpkXAC&pg=PA72&lpg=PA72&dq=Gotcha+%2328+Side+Effects&source=bl&ots=Rn15TlPmje&sig=tymHqta0aSANwaM2GaXC-1Di_tk&hl=en&sa=X&ei=uVKNU47fCcvTsAT6goHIBA&ved=0CCAQ6AEwAA#v=onepage&q=Gotcha%20%2328%20Side%20Effects&f=false

a
 great book, BTW.  Everyone who thinks they know what they are doing 
when they write C++ should read this book!  They will realize that they 
don't know Jack 

Why weren't these and all the other examples of amateur, i.e., 
non-professional, software fixed way back in version 0.3.0 in 2010, before any 
more releases were done?  And why were these and other sub-standard coding 
practices continued and expanded in later releases, right up until the present? 

Ron--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Lets discuss what to do if SHA256d is actually broken

2014-06-03 Thread Rusty Russell 
Luke Dashjr  writes:
> On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
>> Hi,
>> 
>> I thought a lot about the worst case scenario of SHA256d being broken in a
>> way which could be abused to
>> A) reduce the work of mining a block by some significant amount
>> B) reduce the work of mining a block to zero, i.e. allow instant mining.
>
> C) fabricate past blocks entirely.
>
> If SHA256d is broken, Bitcoin as it is fails entirely.

I normally just lurk, but I looked at this issue last year, so thought
I'd chime in.  I never finished my paper though...

In the event of an *anticipated* weakening of SHA256, a gradual
transition is possible which avoids massive financial disruption.

My scheme used a similar solve-SHA256-then-solve-SHA3 (requiring an
extra nonce for the SHA3), with the difficulty of SHA256 ramping down
and SHA3 ramping up over the transition (eg for a 1 year transition,
start with 25/26 SHA2 and 1/26 SHA3).

The hard part is to estimate what the SHA3 difficulty should be over
time.  My solution was to adjust only the SHA3 target on every *second*
difficulty change (otherwise assume that SHA2 and SHA3 have equally
changed rate and adjust targets on both).

This works reasonably well even if the initial SHA3 difficulty is way
off, and also if SHA2 breaks completely halfway through the transition.

I can provide more details if anyone is interested.

Cheers,
Rusty.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Lets discuss what to do if SHA256d is actually broken

2014-06-03 Thread Charlie 'Charles' Shrem 
Hey Rusty,

This is intriguing, do you have a writeup somewhere I can read more about ?

Thanks,

Charlie

CharlieShrem.com | *Please **encrypt messages with my PGP key
*


On Tue, Jun 3, 2014 at 8:45 AM, Rusty Russell  wrote:

> Luke Dashjr  writes:
> > On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
> >> Hi,
> >>
> >> I thought a lot about the worst case scenario of SHA256d being broken
> in a
> >> way which could be abused to
> >> A) reduce the work of mining a block by some significant amount
> >> B) reduce the work of mining a block to zero, i.e. allow instant mining.
> >
> > C) fabricate past blocks entirely.
> >
> > If SHA256d is broken, Bitcoin as it is fails entirely.
>
> I normally just lurk, but I looked at this issue last year, so thought
> I'd chime in.  I never finished my paper though...
>
> In the event of an *anticipated* weakening of SHA256, a gradual
> transition is possible which avoids massive financial disruption.
>
> My scheme used a similar solve-SHA256-then-solve-SHA3 (requiring an
> extra nonce for the SHA3), with the difficulty of SHA256 ramping down
> and SHA3 ramping up over the transition (eg for a 1 year transition,
> start with 25/26 SHA2 and 1/26 SHA3).
>
> The hard part is to estimate what the SHA3 difficulty should be over
> time.  My solution was to adjust only the SHA3 target on every *second*
> difficulty change (otherwise assume that SHA2 and SHA3 have equally
> changed rate and adjust targets on both).
>
> This works reasonably well even if the initial SHA3 difficulty is way
> off, and also if SHA2 breaks completely halfway through the transition.
>
> I can provide more details if anyone is interested.
>
> Cheers,
> Rusty.
>
>
> --
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Bitcoin Core 0.9.2 release candidate 1 is available

2014-06-03 Thread Wladimir 
Bitcoin Core version 0.9.2rc1 is now available from:

  https://bitcoin.org/bin/0.9.2/test

This is a release candidate for a new minor version release, bringing
mostly bug fixes and some minor improvements.
Release candidates are wide-scale testing releases, so use with care.
Non-technical users may want to wait until 0.9.2 final.

Please report bugs using the issue tracker at github:

  https://github.com/bitcoin/bitcoin/issues

Upgrading and downgrading
==

How to Upgrade
--

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

If you are upgrading from version 0.7.2 or earlier, the first time you run
0.9.0 your blockchain files will be re-indexed, which will take anywhere from
30 minutes to several hours, depending on the speed of your machine.

Downgrading warnings


The 'chainstate' for this release is not always compatible with previous
releases, so if you run 0.9.x and then decide to switch back to a
0.8.x release you might get a blockchain validation error when starting the
old release (due to 'pruned outputs' being omitted from the index of
unspent transaction outputs).

Running the old release with the -reindex option will rebuild the chainstate
data structures and correct the problem.

Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan
the blockchain for missing spent coins, which will take a long time (tens
of minutes on a typical machine).

Important changes
==

Gitian OSX build
-

The deterministic build system that was already used for Windows and Linux
builds is now used for OSX as well. Although the resulting executables have
been tested quite a bit, there could be possible regressions. Be sure to report
these on the Github bug tracker mentioned above.

Compatibility of Linux build
-

For Linux we now build against Qt 4.6, and filter the symbols for
libstdc++ and glibc.
This brings back compatibility with

- Debian 6+ / Tails
- Ubuntu 10.04
- CentOS 6.5

0.9.2 Release notes
===

RPC:
- Add `getwalletinfo`, `getblockchaininfo` and `getnetworkinfo` calls
(will replace hodge-podge `getinfo` at some point)
- Add a `relayfee` field to `getnetworkinfo`
- Fix RPC related shutdown hangs and leaks
- Always show syncnode in `getpeerinfo`
- `sendrawtransaction`: report the reject code and reason, and make it
possible to re-send transactions that are already in the mempool
- `getmininginfo` show right genproclimit

Command-line options:
- Fix `-printblocktree` output
- Show error message if ReadConfigFile fails

Block-chain handling and storage:
- Fix for GetBlockValue() after block 13,440,000 (BIP42)
- Upgrade leveldb to 1.17

Protocol and network code:
- Per-peer block download tracking and stalled download detection
- Add new DNS seed from bitnodes.io
- Prevent socket leak in ThreadSocketHandler and correct some proxy
related socket leaks

Wallet:
- Make GetAvailableCredit run GetHash() only once per transaction
(performance improvement)
- Lower paytxfee warning threshold from 0.25 BTC to 0.01 BTC
- Fix importwallet nTimeFirstKey (trigger necessary rescans)
- Log BerkeleyDB version at startup

Build system:
- Add OSX build descriptors to gitian
- Fix explicit --disable-qt-dbus
- Don't require db_cxx.h when compiling with wallet disabled and GUI enabled
- Improve missing boost error reporting
- Upgrade miniupnpc version to 1.9
- gitian-linux: --enable-glibc-back-compat for binary compatibility
with old distributions
- gitian: don't export any symbols from executable
- gitian: build against Qt 4.6
- devtools: add script to check symbols from Linux gitian executables
- Remove build-time no-IPv6 setting

GUI:
- Fix various coin control visual issues
- Show number of in/out connections in debug console
- Show weeks as well as years behind for long timespans behind
- Enable and disable the Show and Remove buttons for requested
payments history based on whether any entry is selected.
- Show also value for options overridden on command line in options dialog
- Fill in label from address book also for URIs
- Fixes feel when resizing the last column on tables (issue #2862)
- Fix ESC in disablewallet mode
- Add expert section to wallet tab in optionsdialog
- Do proper boost::path conversion (fixes unicode in datadir)
- Only override -datadir if different from the default (fixes -datadir
in config file)
- Show rescan progress at start-up
- Show importwallet progress
- Get required locks upfront in polling functions (avoids hanging on locks)
- Catch Windows shutdown events while client is running
- Optionally add third party links to transaction context menu
- Check for !pixmap() before trying to export QR code (avoids crashes
when no QR code