public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] Project status
@ 2011-08-29 20:10 Gavin Andresen
  2011-08-29 20:15 ` Luke-Jr
  2011-08-30  1:09 ` Matt Corallo
  0 siblings, 2 replies; 7+ messages in thread
From: Gavin Andresen @ 2011-08-29 20:10 UTC (permalink / raw)
  To: Bitcoin Dev

Quick brain dump on a bunch of stuff:

I'd like to get a 0.4 release out, but am still working on a fix for
the deadlock bugs that the new wallet encryption and/or the CWallet
refactoring caused. My short-term plan is to reduce the number of
locks and make sure they're always acquired in a consistent order.
Longer term, I think reworking the design to be based on
boost::asio and use fewer threads is probably the right thing to do.

Other things on the 0.4 TODO list:  block chain checkpoint (got a PULL
for that, thanks).  Updated list of hard-coded seed nodes (nanotube
did that last time). Pieter's dump/import privkey patch.

After my talk at the conference, Alex Waters approached me about being
the core bitcoin Q/A lead; he'll be working on creating test plans,
keeping on top of the issues list, testing new features, and
suggesting improvements to the code/test/release process.  And
whatever else he thinks needs to be done to improve core bitcoin.

I'll be rewriting the m-of-n signature "standard transaction" proposal
to mitigate a potential denial-of-service attack that I realized it
would open up (details later, I don't want to give bad guys ideas).


-- 
--
Gavin Andresen



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Bitcoin-development] Project status
  2011-08-29 20:10 [Bitcoin-development] Project status Gavin Andresen
@ 2011-08-29 20:15 ` Luke-Jr
  2011-08-30  1:09 ` Matt Corallo
  1 sibling, 0 replies; 7+ messages in thread
From: Luke-Jr @ 2011-08-29 20:15 UTC (permalink / raw)
  To: bitcoin-development

On Monday, August 29, 2011 4:10:01 PM Gavin Andresen wrote:
> Other things on the 0.4 TODO list:

Can we get some form of the signmessage method in?



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Bitcoin-development] Project status
  2011-08-29 20:10 [Bitcoin-development] Project status Gavin Andresen
  2011-08-29 20:15 ` Luke-Jr
@ 2011-08-30  1:09 ` Matt Corallo
  1 sibling, 0 replies; 7+ messages in thread
From: Matt Corallo @ 2011-08-30  1:09 UTC (permalink / raw)
  To: bitcoin-development

On Mon, 2011-08-29 at 16:10 -0400, Gavin Andresen wrote:
> Quick brain dump on a bunch of stuff:
> 
> I'd like to get a 0.4 release out, but am still working on a fix for
> the deadlock bugs that the new wallet encryption and/or the CWallet
> refactoring caused. My short-term plan is to reduce the number of
> locks and make sure they're always acquired in a consistent order.
> Longer term, I think reworking the design to be based on
> boost::asio and use fewer threads is probably the right thing to do.
Hopefully working on something that would help do this now.
> 
> Other things on the 0.4 TODO list:  block chain checkpoint (got a PULL
> for that, thanks).  Updated list of hard-coded seed nodes (nanotube
> did that last time). Pieter's dump/import privkey patch.
Also my build update pull would be much appreciated.
> 
> After my talk at the conference, Alex Waters approached me about being
> the core bitcoin Q/A lead; he'll be working on creating test plans,
> keeping on top of the issues list, testing new features, and
> suggesting improvements to the code/test/release process.  And
> whatever else he thinks needs to be done to improve core bitcoin.
NICE




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Bitcoin-development] Project status
  2011-09-13 16:48   ` Douglas Huff
@ 2011-09-13 16:53     ` Luke-Jr
  0 siblings, 0 replies; 7+ messages in thread
From: Luke-Jr @ 2011-09-13 16:53 UTC (permalink / raw)
  To: Douglas Huff; +Cc: bitcoin-development

On Tuesday, September 13, 2011 12:48:58 PM Douglas Huff wrote:
> On Sep 13, 2011 11:40 AM, "Luke-Jr" <luke@dashjr•org> wrote:
> > Once created, they must submit the
> > transaction to a staff member with the proper authority to bring it to
> > the offline transaction-signing wallet (on a USB key), where it is
> > signed, and returned to this third wallet.
> 
> I agreed up to this point. Private keys should not be stored on nand.
> Please look in to the data recovery clusterfuck nand creates when
> concerning sensitive data.

I didn't recommend storing private keys on NAND. The USB stick would contain 
only the transaction that it being approved, and the offline-signing-wallet 
would sign it. The USB stick then contains only the signed transaction to be 
returned to an online node. At no time does it contain keys.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Bitcoin-development] Project status
  2011-09-13 16:40 ` Luke-Jr
@ 2011-09-13 16:48   ` Douglas Huff
  2011-09-13 16:53     ` Luke-Jr
  0 siblings, 1 reply; 7+ messages in thread
From: Douglas Huff @ 2011-09-13 16:48 UTC (permalink / raw)
  To: Luke-Jr; +Cc: bitcoin-development

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

On Sep 13, 2011 11:40 AM, "Luke-Jr" <luke@dashjr•org> wrote:
> Once created, they must submit the
> transaction to a staff member with the proper authority to bring it to the
> offline transaction-signing wallet (on a USB key), where it is signed, and
> returned to this third wallet.

I agreed up to this point. Private keys should not be stored on nand. Please
look in to the data recovery clusterfuck nand creates when concerning
sensitive data.

It is close to impossible to reliably delete such data, moreso on usb keys
than ssd, short of absolute physical destruction and noone should be
recommending this. Ever.

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Bitcoin-development] Project status
  2011-09-13 14:43 Gavin Andresen
@ 2011-09-13 16:40 ` Luke-Jr
  2011-09-13 16:48   ` Douglas Huff
  0 siblings, 1 reply; 7+ messages in thread
From: Luke-Jr @ 2011-09-13 16:40 UTC (permalink / raw)
  To: bitcoin-development

On Tuesday, September 13, 2011 10:43:27 AM Gavin Andresen wrote:
> 3) I'd really like to come to consensus on one or more
> 'multi-signature' standard transactions to enable much better wallet
> backup and security.

More important in this area, IMO, is support for deterministic keychains in 
wallets. Type 2, according to gmaxwell's original spec, seems pretty ideal, 
and significantly improves security for many use cases. Since it allows a 
wallet to contain a public keychain without the matching private keychain, 
webservers, POS, and other services can be provisioned only with the keychain 
required to generate/access infinite public keys, and without the private 
keyroot needed to spend them.

The ideal scenario in this regard, as I see it, is this:
- Webserver wallets are provisioned with multiple public keychains (one per 
webserver), and configured to use a specific one for getnewaddress/etc. By 
provisioning them with *all* the public keychains, their listtransactions/etc 
can see the transactions sent to other webservers, necessary to show 
confirmations to the end user and such.
- Business keeps a locked-down *offline* wallet with the private keychains for 
all the forementioned public keychains. Only this wallet has the information 
required to spend the income. The wallet is encrypted, and can only be 
accessed by staff with the proper position/authority to authorize expenses.
- A third wallet is used by staff to prepare expense transactions. It keeps 
track of locking coins it knows are in the process of being spent, and any 
staff member can create new ones. Once created, they must submit the 
transaction to a staff member with the proper authority to bring it to the 
offline transaction-signing wallet (on a USB key), where it is signed, and 
returned to this third wallet.


Another feature that needs some attention is signmessage. It can be used to 
send a transaction id/summary to a specified email address signed by the 
sending key of the same transaction (these can be added to the send-money 
GUI). This would allow merchants to publish a single payment address and still 
be able to verify which customers sent payment.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bitcoin-development] Project status
@ 2011-09-13 14:43 Gavin Andresen
  2011-09-13 16:40 ` Luke-Jr
  0 siblings, 1 reply; 7+ messages in thread
From: Gavin Andresen @ 2011-09-13 14:43 UTC (permalink / raw)
  To: Bitcoin Dev

0.4 RELEASE

Bitcoin version 0.4 release candidate 2 looks stable; I've been
running a slightly-modified version of it on the Faucet website with
no issues for a couple of days now, and am not aware of any
show-stopper issues.

I built and uploaded OSX binaries to github:
  https://github.com/bitcoin/bitcoin/downloads

Windows and Linux binaries will appear as soon as our "gitian-capable"
builders get a minute to create them (Jeff and Matt have been busy
with real life or their day jobs).

I'd like to switch from distributing binaries on SourceForge to
distributing them on GitHub, since GitHub supports https downloads.


NEXT RELEASE

If you have patches waiting to be pulled, now would be a good time to
rebase them; I expect minimal-to-no changes between release candidate
2 and the final 0.4 release.

And, if you haven't already, write up a little test plan and/or add
some unit tests.

The big planned feature for next release is switching from wxWidgets
to qt for the GUI client.

ON THE RADAR

I'm going to start separate discussions about a few need-deep-thinking issues:

1) There is a bug/design flaw in bitcoin's difficulty adjustment
algorithm. More generally, there have been nagging issues surrounding
how bitcoin handles time that I think need to be addressed.

2) I'm going to submit pull requests for an implementation of the
"don't talk to misbehaving peers" idea. That should proactively
prevent a whole swath of potential denial-of-service attacks, but if I
got it wrong it could be very bad for the network.

3) I'd really like to come to consensus on one or more
'multi-signature' standard transactions to enable much better wallet
backup and security.

Lets talk about those three issues in separate threads.

-- 
--
Gavin Andresen



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2011-09-13 17:57 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-29 20:10 [Bitcoin-development] Project status Gavin Andresen
2011-08-29 20:15 ` Luke-Jr
2011-08-30  1:09 ` Matt Corallo
2011-09-13 14:43 Gavin Andresen
2011-09-13 16:40 ` Luke-Jr
2011-09-13 16:48   ` Douglas Huff
2011-09-13 16:53     ` Luke-Jr

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox