Michael Hendricks [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-10-24 to 2013-11-22
💬 Posted a total of 11 messages
📚 Participated in the following categories: Bitcoin-development, PATCH
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:09:55

- reply

📅 Original date posted:2013-11-22
📝 Original message:Wrong patch? This looks like node.js code for something called txtool.
--
Michael
On Fri, Nov 22, 2013 at 1:46 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> Trying something new... a [simple] patch sent to the list, for
> discussion. Seems unlikely to be controversial. github access is
> temporarily disabled, so this is the best pull request avenue for the
> moment.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131122/ce3833ea/attachment.html>

2023-06-07 15:05:02

- reply

📅 Original date posted:2013-07-23
📝 Original message:On Tue, Jul 23, 2013 at 4:36 AM, Pieter Wuille <pieter.wuille at gmail.com>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 should be exposed in the P2P
> protocol, which is inevitable, and already has some DoS protections.
>
> I like this HTTP interface, but it should really only be used for
> trusted local applications and debugging.
>
We already have a good private HTTP interface. Most benefits of this REST
interface come from exposing it publicly. As always, the challenge is
balancing costs and benefits. I'm not confident that either can be known
with certainty until a well-written prototype is running in the wild. As
some nodes expose this interface, we'll gain concrete experience from which
node operators can make informed security trade offs.
--
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130723/8d1b3f10/attachment.html>

2023-06-07 15:04:55

- reply

📅 Original date posted:2013-07-22
📝 Original message:+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 helpful, eventually, to have APIs corresponding to Bitcoin addr and
version messages. Metadata about the network and the peer, respectively,
are valuable in my use cases.
Michael
On Jul 22, 2013 1:43 PM, "Jeff Garzik" <jgarzik at bitpay.com> wrote:
> URL: https://github.com/bitcoin/bitcoin/pull/2844
>
> Adding an HTTP REST API for bitcoind has been occasionally tossed
> about as a useful thing. Such an API would essentially provide a
> decentralized block explorer capability, enabling easy external access
> to transaction/address/block indices that we maintain.
>
> The first two implemented API calls are simple, returning a block or
> TX given a simple query string based on block hash, e.g.
>
> GET /rest/tx/TX-HASH
> or
> GET /rest/block/BLOCK-HASH
>
> This can be easily accessed via command line cURL/wget utilities.
> Output formats -- binary, hex or json -- may be selected via a
> "bitcoin-format" header.
>
> The general goal of the HTTP REST interface is to access
> unauthenticated, public blockchain information. There is no plan to
> add wallet interfacing/manipulation via this API.
>
> --
> Jeff Garzik
> Senior Software Engineer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130722/2c0063e6/attachment.html>

2023-06-07 15:02:39

- reply

📅 Original date posted:2013-06-03
📝 Original message:On Mon, Jun 3, 2013 at 5:43 PM, Melvin Carvalho <melvincarvalho at gmail.com>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130603/2d82b7c7/attachment.html>

2023-06-07 15:02:33

- reply

📅 Original date posted:2013-05-31
📝 Original message:On Fri, May 31, 2013 at 5:56 AM, Rune Kjær Svendsen <runesvend at gmail.com>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 necessarily quick enough to finish its
> work before a new block comes in and the app is executed again.
>
In a similar circumstance, I changed my -blocknotify script to quickly
append necessary information to a queue and immediately exit. A separate
script runs at all times monitoring this queue for work and performs the
labor intensive calculations.
I hope that helps.
--
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130531/82acd521/attachment.html>

2023-06-07 03:00:59

- reply

📅 Original date posted:2012-01-31
📝 Original message:On Tue, Jan 31, 2012 at 12:17 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Jan 30, 2012 at 11:33 PM, Michael Hendricks <michael at ndrix.org> 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 not to mixup addrman created issues with preexisting ones
> simply related to the number of connections vs the number of nodes.
> Even absent addressman someone who can spin up a large multiple of the
> current nodes as tcp forwarders to a system they control can capture
> all of a nodes outbound connections.
I think I've explained myself poorly. On my nodes, the old address
database routinely has 120k addresses. With the new address manager,
it will have 20k addresses. Filling the former with 60% evil nodes
requires 72,000 evil nodes; while the latter requires 12,000.
As I mentioned in my first post, I think the new address manager "is a
valuable improvement over what we have today". I think it should be
included in the next release.
I also think we should be aware that we're making it somewhat easier
to isolate outbound-only nodes. A single listening node can support
15 non-listening nodes (125/8). The network currently has 5
non-listening nodes for every listening node. That ratio has stayed
quite stable, so I think we have wiggle room if we wanted to allow
more outbound connections in some circumstances.
--
Michael

2023-06-07 03:00:55

- reply

2023-06-07 03:00:49

- reply

📅 Original date posted:2012-01-31
📝 Original message:On Mon, Jan 30, 2012 at 7:05 PM, Gavin Andresen <gavinandresen at gmail.com> 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 to have a (say) 1% chance of a
> successful Sybil attack?
The randomness prevents finely crafted attacks since an attacker can't
predict which bucket his address ends up in. I don't think it helps
against brute force attacks though. If 60% of the network's nodes are
controlled by an evil botnet, 60% of the nodes we pull out of the
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. At
current network size, 60% of listening nodes is 2,800; only 2-5% of a
decent botnet.
Nodes that accept incoming connections are far less vulnerable, since
the probability of success decreases exponentially with the number of
connections. 95% botnet control with 125 connections has 10^-6 chance
of success.
Perhaps we could add a command-line option for increasing the maximum
number of outbound connections. That way, nodes unable to accept
incoming connections can easily decrease their susceptibility to Sybil
attack.
> I've also been wondering if it is time to remove the IRC bootstrapping
> mechanism; it would remove a fair bit of code and we'd stop getting
> reports that various ISPs tag bitcoin as malware. When testing the
> list of built-in bootstrapping IP addresses I always connect fairly
> quickly, and the DNS seeding hosts seems to be working nicely, too.
I think it should be disabled by default one release after the new
address manager is released. That way, we're not changing too many
parts of the bootstrapping process at once.
As an aside, I can't help but wonder whether ISPs blocking IRC traffic
filters some botnets out of the IRC bootstrapping channels; keeping
them more "pure".
--
Michael

2023-06-07 03:00:30

- reply

📅 Original date posted:2012-01-30
📝 Original message:On Sun, Jan 29, 2012 at 7:31 PM, Pieter Wuille <pieter.wuille at gmail.com> 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, and sorted on last-seen time
> with some randomization. For some people this lead to multi-megabyte
> addr.dat files that took ages (well, seconds) to load.
I think this is a great change for IPv4 too. On certain machines with
slow IO, I routinely delete the address database before starting
bitcoind to improve load times.
> After some discussion with Gregory Maxwell and others on IRC, I
> decided to write a specialized address manager based on an entirely
> different principle: only keep a limited number of addresses, keep and
> index them in-memory, and only occasionally (and asynchronously) dump
> them to disk.
I've started a couple patches with a similar design, but not produced
anything I'm happy with. That work has persuaded me that this
architecture is a valuable improvement over what we have today.
> This of course leads to a weakness: attackers may try to
> poison your entire address cache with addresses they control, in order
> to perform a Sybil attack. This is especially dangerous in the context
> of IPv6, where much more possible addresses exist.
If the Bitcoin client has multiple peer discovery methods enabled
(IRC, DNS, seed nodes, etc), it might be wise to guarantee that at
least one peer is selected via each method. This requires a Sybil
attacker to control all peer discovery methods for a successful
attack.
> To protect against this, we came up with this design: keep two tables:
> one that keeps addresses we've had actual connections with, and one
> that maintains untried/new addresses. Both are separated into several
> limited-size buckets. Each tables provides a level of protection
> against sybil attacks:
> * Addresses in the first table are placed in one of only a few
> buckets chosen based on the address range (/16 for IPv4). This way, an
> attacker cannot have tons of active nodes in the same /16 range, and
> use those to fill the table.
> * Addresses in the second table are placed in one of a few buckets
> chosen based on address range the information came from, instead of
> the address itself. This way, an attacker spamming you with tons of
> "addr" messages can only still have a limited effect.
Cool design. It seems resilient to many attacks. A Sybil attack
coming from a large botnet (which controls addresses in many ranges)
can still fill all buckets in both tables, I think. As far as I can
tell, that wasn't possible with the old design.
--
Michael

2023-06-07 02:40:16

- reply

📅 Original date posted:2011-11-17
🗒️ Summary of this message: A user reports a strange behavior with the 0.5.0 version of Bitcoin-QT in Linux, where the blockchain stops downloading at 10% and then restarts at 0% after closing and reopening the client. The issue has been noticed before and needs fixing. The number of connections can be found by hovering over the signal icon.
📝 Original message:2011/11/17 Martinx - ジェームズ <thiagocmartinsc at gmail.com>
> 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 of the blockchain is working, reach 15% and growing...
>
I've noticed this same behavior with 0.5 release candidates. I remember
seeing it with 0.4 also, so I think it's not a regression. I haven't yet
pinned down the cause. It would be nice to fix; especially for those
downloading the blockchain for the first time.
Also, where can I find the number of connections using new Bitcoin-QT?
>
Hover over the signal icon in the lower right corner. The icon looks like
a cellphone signal indicator. The number of connections is displayed in a
tooltip.
--
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111117/534407c9/attachment.html>

2023-06-07 02:35:01

- reply

📅 Original date posted:2011-10-24
🗒️ Summary of this message: Gavin Andresen suggests a potential issue with the "listtransactions" feature and proposes a solution to avoid performance penalties for users.
📝 Original message:On Mon, Oct 24, 2011 at 8:55 AM, Gavin Andresen <gavinandresen at gmail.com>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 fetching all the previous inputs from disk
> just so you can check to see if they're 'green' violates the "a
> feature shouldn't cost anything if it is not being used" design
> principle.
>
Are there current users of gettransaction for whom the performance penalty
would be problematic? If so, perhaps gettransaction could take an optional
second argument includeinputaddresses which defaults to false.
--
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111024/376c13b2/attachment.html>