Bitcoin Forum
December 06, 2016, 04:15:05 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: On IRC bootstrapping  (Read 15109 times)
sirius
Bitcoiner
Staff
Sr. Member
****
Offline Offline

Activity: 429



View Profile
July 07, 2010, 01:05:47 AM
 #21

Maybe we should have an option dialog that allows you to choose the IRC server and channel you connect to?

Identifi - Decentralized address book with trust ratings
I'm not a forum admin - please contact theymos instead.
1481040905
Hero Member
*
Offline Offline

Posts: 1481040905

View Profile Personal Message (Offline)

Ignore
1481040905
Reply with quote  #2

1481040905
Report to moderator
1481040905
Hero Member
*
Offline Offline

Posts: 1481040905

View Profile Personal Message (Offline)

Ignore
1481040905
Reply with quote  #2

1481040905
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481040905
Hero Member
*
Offline Offline

Posts: 1481040905

View Profile Personal Message (Offline)

Ignore
1481040905
Reply with quote  #2

1481040905
Report to moderator
1481040905
Hero Member
*
Offline Offline

Posts: 1481040905

View Profile Personal Message (Offline)

Ignore
1481040905
Reply with quote  #2

1481040905
Report to moderator
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
July 07, 2010, 01:31:07 AM
 #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.
Vasili Sviridov
Member
**
Offline Offline

Activity: 104


View Profile WWW
July 16, 2010, 07: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.

1JHYtsmsGq2McwGHmWayVjVtHds8rp1R5
laszlo
Full Member
***
Offline Offline

Activity: 199


View Profile
July 16, 2010, 08: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.

BC: 157fRrqAKrDyGHr1Bx3yDxeMv8Rh45aUet
PulsedMedia
Sr. Member
****
Offline Offline

Activity: 402


View Profile WWW
July 18, 2010, 04: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.

http://PulsedMedia.com - Semidedicated rTorrent seedboxes
aceat64
Full Member
***
Offline Offline

Activity: 127



View Profile
July 22, 2010, 06: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).

Quantumplation
Member
**
Offline Offline

Activity: 84


View Profile
July 22, 2010, 07: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.

Against my better judgement... 1ADjszXMSRuAUjyy3ShFRy54SyRVrNDgDc
aceat64
Full Member
***
Offline Offline

Activity: 127



View Profile
July 22, 2010, 08: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.

Quantumplation
Member
**
Offline Offline

Activity: 84


View Profile
July 22, 2010, 08: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?

Against my better judgement... 1ADjszXMSRuAUjyy3ShFRy54SyRVrNDgDc
martin
Full Member
***
Offline Offline

Activity: 150



View Profile WWW
July 22, 2010, 08:39:12 PM
 #30

Actually, distributed name resolution (and thus bootstrapping without a central authority) is possible

Vasili Sviridov
Member
**
Offline Offline

Activity: 104


View Profile WWW
July 22, 2010, 10: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...

1JHYtsmsGq2McwGHmWayVjVtHds8rp1R5
Cheater
Newbie
*
Offline Offline

Activity: 13


View Profile
July 23, 2010, 12:26:18 PM
 #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.
Quantumplation
Member
**
Offline Offline

Activity: 84


View Profile
July 23, 2010, 12:45:14 PM
 #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?

Against my better judgement... 1ADjszXMSRuAUjyy3ShFRy54SyRVrNDgDc
Cheater
Newbie
*
Offline Offline

Activity: 13


View Profile
July 23, 2010, 10: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.
NewLibertyStandard
Sr. Member
****
Offline Offline

Activity: 252



View Profile WWW
July 24, 2010, 04: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.

Treazant: A Fullever Rewarding Bitcoin - Backup Your Wallet TODAY to Double Your Money! - Dual Currency Donation Address: 1Dnvwj3hAGSwFPMnkJZvi3KnaqksRPa74p
Quantumplation
Member
**
Offline Offline

Activity: 84


View Profile
July 24, 2010, 08: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.

Against my better judgement... 1ADjszXMSRuAUjyy3ShFRy54SyRVrNDgDc
mizerydearia
Hero Member
*****
Offline Offline

Activity: 574



View Profile
May 13, 2011, 09: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?
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
May 13, 2011, 10: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 :-)

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
WakiMiko
Jr. Member
*
Offline Offline

Activity: 59



View Profile
May 14, 2011, 09: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

1APeJ2DiUNdsNizn47MBeAwbjaugEgg4Zn
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
May 14, 2011, 10: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?

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!