Pages:
Author

Topic: On IRC bootstrapping (Read 26668 times)

hero member
Activity: 489
Merit: 504
May 14, 2011, 06:43:42 AM
#40
Rehashing would be one option to solve the sha-1 vs sha-256 mismatch. Or we could just keep the last 160 bits of the sha-256 hash trunkating the first 0s so the hash would still be recognizable :-)
Should I try and create a separate thread to this?
newbie
Activity: 59
Merit: 0
May 14, 2011, 05:13:06 AM
#39
I'm sure I mentioned it elsewhere already but how about just choosing a random hash (genesis block for example) and then using that hash to find peers from a BitTorrent tracker.
I'm sure the tracker won't mind, and exchanging IPs is their main business :-)

This sounds like a pretty good idea. Using the hash of the genesis block would allow for several blockchains (e.g. testnet) to use the same trackers without problems.

Bittorrent uses urlencoded 20 byte sha1 hashes when requesting information from a tracker, so I came up with the following in python:

Code:
import hashlib
import urllib

sha256 = '000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f'.decode('hex')
sha1 = hashlib.sha1(sha256).digest()
print urllib.quote(sha1)

which returns %84%EB%CAI.T%C6h/%1B%84i%82%80%F0%7B%8B%8F%C5%06

an example request could look like this: http://46.4.13.200:6969/announce?info_hash=%84%EB%CAI.T%C6h/%1B%84i%82%80%F0%7B%8B%8F%C5%06
hero member
Activity: 489
Merit: 504
May 13, 2011, 06:14:58 PM
#38
I'm sure I mentioned it elsewhere already but how about just choosing a random hash (genesis block for example) and then using that hash to find peers from a BitTorrent tracker.
I'm sure the tracker won't mind, and exchanging IPs is their main business :-)
hero member
Activity: 574
Merit: 507
May 13, 2011, 05:14:42 PM
#37
I'm bringing this topic to attention again to continue discussing about bootstrapping methods in which many addresses are currently hardcoded into the Bitcoin client.  Are the hardcoded ip addresses permanently reliable?

How about security concerns such as possibility of those ip addresses being compromised and directed to a fork of bitcoin p2p network?
sr. member
Activity: 308
Merit: 250
July 24, 2010, 04:28:32 AM
#36
It is completely distributed. You just need a small list to start with.
The initial list is only required for the first run and if caches drop off or if there are new ones you simply update the list for the next version. Its not critical.

Its light years above the current IRC method. :p
Very light weight, simple and distributed.

"completely distributed" and "need a small list to start with" are mutually exclusive.  If you need a small list to start with, that's your single point of failure, and should those go down, you're completely locked out of the network.  Same with IRC.  It's EXACTLY like IRC, except that in IRC the list is a live snapshot of who's really on the network.

It's not any better than the current IRC method.  IRC is an extremely lightweight protocol to implement.

IRC is only used for the initial connection or two.  After that, it communicates with those it connects to in order to find more, exactly as described in your system.
sr. member
Activity: 252
Merit: 268
July 24, 2010, 12:17:55 AM
#35
It is completely distributed. You just need a small list to start with.
The initial list is only required for the first run and if caches drop off or if there are new ones you simply update the list for the next version. Its not critical.

Its light years above the current IRC method. :p
Very light weight, simple and distributed.
Bitcoin already contains a short list of hard coded addresses and everyone's clients can find everyone else's clients if IRC were to go down or if the #bitcoin channel locked everyone out.
newbie
Activity: 13
Merit: 0
July 23, 2010, 06:35:51 PM
#34
It is completely distributed. You just need a small list to start with.
The initial list is only required for the first run and if caches drop off or if there are new ones you simply update the list for the next version. Its not critical.

Its light years above the current IRC method. :p
Very light weight, simple and distributed.
sr. member
Activity: 308
Merit: 250
July 23, 2010, 08:45:14 AM
#33
as it was designed to be completely distributed and not controlled by a central party.

A list of 10 to 20 hard coded in to the client gets it going to start with.

... wat?
newbie
Activity: 13
Merit: 0
July 23, 2010, 08:26:18 AM
#32
I actually run a GWebCache and it is perfect for bootstrapping purposes as it was designed to be completely distributed and not controlled by a central party.

With a single HTTP request, you get both many nodes to connect to and also alternative caches to use in the future.
A list of 10 to 20 hard coded in to the client gets it going to start with.

Its been proven to work exceptionally well and it would take only a small amount of effort to add.
member
Activity: 102
Merit: 10
July 22, 2010, 06:45:05 PM
#31
Actually, distributed name resolution (and thus bootstrapping without a central authority) is possible

Requires IPv6. We're not quite there yet...
full member
Activity: 150
Merit: 100
July 22, 2010, 04:39:12 PM
#30
Actually, distributed name resolution (and thus bootstrapping without a central authority) is possible
sr. member
Activity: 308
Merit: 250
July 22, 2010, 04:15:33 PM
#29
Thereby is the issue.

So, if all we're looking for is a single connection, why overcomplicate it?  Why not just keep the IRC bootstrapping?
full member
Activity: 307
Merit: 102
July 22, 2010, 04:10:27 PM
#28
is pool.ntp.org run from a central authority, or is it somehow a distributed network?  I'm not sure how you'd maintain that list of "stable" IP's without some central authority that lists them.

There is a central authority, but I don't see that as being an issue since all we're talking about is bootstrapping. Unfortunately every bootstrap method I can think of includes some form of central authority.
sr. member
Activity: 308
Merit: 250
July 22, 2010, 03:02:46 PM
#27
is pool.ntp.org run from a central authority, or is it somehow a distributed network?  I'm not sure how you'd maintain that list of "stable" IP's without some central authority that lists them.
full member
Activity: 307
Merit: 102
July 22, 2010, 02:58:53 PM
#26
How about a system similar to pool.ntp.org? Basically we have an opt-in list of nodes of very stable nodes and those IPs are added to a round-robin DNS record. Optionally, we could have an automated maintenance script that updates the DNS record at set intervals to remove IPs that are no longer accessible. I feel that this system would be preferable to hard-coding IPs into the client. This method should allow fast and easy bootstrapping using a proven system (DNS).
sr. member
Activity: 402
Merit: 250
July 18, 2010, 12:03:35 AM
#25
Hope the seedlist is long and those are fast peers able to take a pounding.
When given enough incentive, even the root DNS servers are in danger (most of them got taken down couple years back by a DDoS), so the list needs to be long, and those nodes need to be able to take it.

So the list should be atleast 1000 nodes, for which it doesn't incur too much damage if getting DDoS'd. Even if they are average 100Mbps nodes, or even 1GigE, it's tho still easy to drop. Freenet + Seedlist i don't see to be enough in the long term. Adding a node to connect to manually just is not an option (the same list posted here in forums could be as easily be DDoS'd).

Maybe with an list of 10,000 nodes eventually, and random trying networks with dynamic dhcp pools where it's known that there's a lot of bitcoin users (couple ISPs) as tertiary fallback. Those along with static HTTP (trusted volunteer maintained ones) and dns pointers (trusted volunteer maintained ones aswell) would proof to be enough fallbacks for not to worry.

Admittedly, this is not a problem today, but as BC grows and it's value grows, i'm very certain there's a huge interest and incentive to disrupt it for some people. People with huge resources. Think if an 5mil node botnet is used for an attack... Maybe even with just 2Mbps average outbound it would account to 10Tbit/s attack.

For now however, it's enough.
full member
Activity: 199
Merit: 2072
July 16, 2010, 04:30:31 PM
#24
The current bootstrapping mechanisms are working pretty well and we can scale them as demand goes up.  If you're unable to connect through IRC or the alternate built in seeding system then you can always use -addnode=1.2.3.4 to specify the address of a running node.  Once you have discovered a node and connected you will get the addresses of all the other nodes via the bitcoin protocol and don't need the seeding systems to be able to get on the network.  Even if IRC failed you could use one of the addresses from the Static IP Address thread here to connect the first time.
member
Activity: 102
Merit: 10
July 16, 2010, 03:31:39 PM
#23
What about piggybacking off a torrent tracker? When people are downloading via bittorrent their IP addresses are kept by the tracker and are available for all nodes that connect. Maybe there could be a tiny file, announced on the multiple public trackers. While people "seed" it, their addresses are known and available as initial peer addresses. There are many public trackers available currently, with little chance all of them will be shut down at once.
founder
Activity: 364
Merit: 6472
July 06, 2010, 09:31:07 PM
#22
Everybody needs to connect to the same IRC server and channel so they can find each other.

You may want to leave Freenode in as a fallback server -- if his server doesn't work, use Freenode's.
It might not be good if we suddenly rushed freenode with a ton of users all at once.

The fallback is our own seed system.

irc.lfnet.org is pretty old and has impressive uptime.  I think it's going to be fine.

We could take IRC out at some point if we want, but I'd rather ease into it and just test our own seed system as a backup for now, and I really like the complementary redundant attributes of the two different systems.
sr. member
Activity: 429
Merit: 919
July 06, 2010, 09:05:47 PM
#21
Maybe we should have an option dialog that allows you to choose the IRC server and channel you connect to?
Pages:
Jump to: