Re: [Bitcoin-development] [PATCH] bitcoind: whitelist nodes, to prevent them from being banned

2013-11-22 Thread Michael Hendricks
Wrong patch? This looks like node.js code for something called txtool. -- Michael On Fri, Nov 22, 2013 at 1:46 PM, Jeff Garzik wrote: > Trying something new... a [simple] patch sent to the list, for > discussion. Seems unlikely to be controversial. github access is > temporarily disabled,

Re: [Bitcoin-development] HTTP REST API for bitcoind

2013-07-23 Thread Michael Hendricks
On Tue, Jul 23, 2013 at 4:36 AM, Pieter Wuille wrote: > Apart from that, exposing this HTTP-based interface publicly has its > own problems, like security risks and potential DoS risks. If > anything, we should be reducing the attack surface rather than > increase it. IMHO, the only thing that sho

Re: [Bitcoin-development] HTTP REST API for bitcoind

2013-07-22 Thread Michael Hendricks
+1 and thank you. I've prototyped a couple different Bitcoin projects that would benefit from this. I'm traveling with poor 'net so I haven't read the patches yet. I echo pull request comments about using Accept and Accept-Encoding headers. Same for an API version number in the URL. It'd be helpf

Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

2013-06-03 Thread Michael Hendricks
On Mon, Jun 3, 2013 at 5:43 PM, Melvin Carvalho wrote: > Sorry if this is a stupid question, but why would someone want to > sacrifice their bitcoins? > Good question. One reason is https://en.bitcoin.it/wiki/Fidelity_bonds Cheers, Michael ---

Re: [Bitcoin-development] Implementing batch processing for -blocknotify

2013-05-31 Thread Michael Hendricks
On Fri, May 31, 2013 at 5:56 AM, Rune Kjær Svendsen wrote: > I have an application that wants to keep up with new blocks as they come > in. For that I can use the -blocknotify option with bitcoind, which will > execute my application for each new block. > > The problem is that my app isn't necessa

Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager

2012-01-31 Thread Michael Hendricks
On Tue, Jan 31, 2012 at 12:17 AM, Gregory Maxwell wrote: > On Mon, Jan 30, 2012 at 11:33 PM, Michael Hendricks wrote: >> address manager point to the attacker.  If a client has 8 connections >> to the network, a Sybil attack would succeed 1.7% of the time. > > Meh, careful

Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager

2012-01-31 Thread Michael Hendricks
On Tue, Jan 31, 2012 at 12:17 AM, Gregory Maxwell wrote: > On Mon, Jan 30, 2012 at 11:33 PM, Michael Hendricks wrote: >> address manager point to the attacker.  If a client has 8 connections >> to the network, a Sybil attack would succeed 1.7% of the time. > > Meh, careful

Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager

2012-01-30 Thread Michael Hendricks
On Mon, Jan 30, 2012 at 7:05 PM, Gavin Andresen wrote: > Given the randomness in Pieter's design, that seems extremely unlikely > / difficult to do. Is it possible to do a back-of-the-envelope > calculation to figure out what percentage of nodes on the network an > attacker would have to control t

Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager

2012-01-30 Thread Michael Hendricks
On Sun, Jan 29, 2012 at 7:31 PM, Pieter Wuille wrote: > wanting to move to IPv6 support in the Satoshi bitcoin client > somewhere in the future, the way IP addresses were managed is not > really possible anymore. Right now, basically all addresses ever seen > are kept - both on-disk and in-memory,

Re: [Bitcoin-development] Release candidates: versions 0.4.1 and 0.5

2011-11-17 Thread Michael Hendricks
2011/11/17 Martinx - ジェームズ > Testing the 0.5.0 in Linux, I see a strange behaviour: > > 1- Open qt-client, blockchain stops the downloading at 10%... Wait 30 > minutes... not reach 11%... > > 2- Close and reopen the qt-client, blockchain start again at 0%... > Normal!? > > 3- Now the download

Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-24 Thread Michael Hendricks
On Mon, Oct 24, 2011 at 8:55 AM, Gavin Andresen wrote: > If you assume the client has all previous transactions, then you could > get the transaction input's prevout (from the memory pool or disk) and > then ExtractAddress() from it. That is probably a bad idea for > listtransactions, since fetchi