Re: [Bitcoin-development] [QT] Feature proposal: Displaying current Units/Changing Units with status bar control.

2014-06-02 Thread sebastien requiem
Hello Angel,

Good initiative. This looks good. If I understand, the dropdown menu is for
the whole application, so it make sense to have it in a common part of the
layout.

A slight optimisation would be to write the unit in the transaction table
header too (since we read from top to bottom). This would give something
like Amount (mBTC). That way, the user doesn't have to think twice about
the unit of his values.


Hope it helps,





On Fri, May 30, 2014 at 6:39 PM, Angel Leon gubat...@gmail.com wrote:

 There's been quite a lot of debate over the default unit of display to
 use, you can read the conversation here, which was closed.
 https://github.com/bitcoin/bitcoin/issues/3862

 Whatever the side of the debate you're on, wether it should be BTC or
 mBTC, or other, regular users will probably take too long to find a way to
 change the current unit of display, and if the unit of display were ever
 changed to something other than BTC, the current transaction tablesAmount
 column don't mention anywhere what Unit of Display is being used.

 So last night I started playing with the idea of having a status bar
 component that would:
 1. Show you what is the current unit of display at all times.
 2. Let you change the unit of display easily.

 Here's how it looks (see attachment), just wanted to get feedback, if this
 is something you also consider valuable in terms of user experience, or
 maybe you don't want to allow any more controls on the status bar (because
 then people will want to add more and more)

 Just want to get some feedback before I continue working on this to polish
 it and submit a pull request.


 Cheers.
 Angel (@gubatron)


 --
 Time is money. Stop wasting it! Get your web API in 5 minutes.
 www.restlet.com/download
 http://p.sf.net/sfu/restlet
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
sebastien requiem
--
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] [QT] Feature proposal: Displaying current Units/Changing Units with status bar control.

2014-06-02 Thread Wladimir
On Fri, May 30, 2014 at 6:39 PM, Angel Leon gubat...@gmail.com wrote:

 Here's how it looks (see attachment), just wanted to get feedback, if this
 is something you also consider valuable in terms of user experience, or
 maybe you don't want to allow any more controls on the status bar (because
 then people will want to add more and more)

Looks good to me.

Though we already allow specifying a unit in all places where the user
can specify a BTC amount.

We also already show the unit in all places where amounts are shown,
except the tables, would be good to add a [unit] in the header there
as well, see https://github.com/bitcoin/bitcoin/issues/3970 .

If that is done, I'm not sure how much a global setting in the status
bar would add. It may make it more apparent to the user that multiple
units can be selected.

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] [QT] Feature proposal: Displaying current Units/Changing Units with status bar control.

2014-06-02 Thread Gregory Maxwell
On Mon, Jun 2, 2014 at 12:39 AM, Wladimir laa...@gmail.com wrote:
 If that is done, I'm not sure how much a global setting in the status
 bar would add. It may make it more apparent to the user that multiple
 units can be selected.

If thats done it should be done in a way in which it's impossible that
a stray keypress could switch it or someone may eventually have a very
very bad day.

--
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] Another uninitialized memory problem

2014-06-02 Thread Toshi Morita
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


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

2014-06-02 Thread xor
-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


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

2014-06-02 Thread Luke Dashjr
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