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?
Topic: On IRC bootstrapping (Read 26758 times)
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 :-)
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)
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
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 :-)
I'm sure the tracker won't mind, and exchanging IPs is their main business :-)
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?
How about security concerns such as possibility of those ip addresses being compromised and directed to a fork of bitcoin p2p network?
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.
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.
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. 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.
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.
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.
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?
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.
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.
Actually, distributed name resolution (and thus bootstrapping without a central authority) is possible
Requires IPv6. We're not quite there yet...
Actually, distributed name resolution (and thus bootstrapping without a central authority) is possible
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?
So, if all we're looking for is a single connection, why overcomplicate it? Why not just keep the IRC bootstrapping?
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.
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.
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).
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.
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.
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.
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.
Everybody needs to connect to the same IRC server and channel so they can find each other.
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.
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.
Maybe we should have an option dialog that allows you to choose the IRC server and channel you connect to?
Jump to: