Thanks. Where do I enter those commands? The pat "C:\Program Files (x86)\Bitcoin\bitcoin.exe -noirc -dnsseed" didnt work.
the quotes has to stop after .exe 
Topic: New IRC bootstrapping using random channels. (Read 5594 times)
Thanks. Where do I enter those commands? The pat "C:\Program Files (x86)\Bitcoin\bitcoin.exe -noirc -dnsseed" didnt work.
Start bitcoin with: bitcoin -noirc -dnsseed
This will disable IRC seeding, and use the new DNS seeding method.
This will disable IRC seeding, and use the new DNS seeding method.
My university ISP banned me from their network because of the IRC connections. I apparently connected to an IP on their blocklist on port 6667 and they assumed my pc was part of a botnet that got directions from that IP.
I now have blocked all incoming and outgoing traffic on port 6667 on my pc but I am not sure if bitcoin is working anymore. Is there a solution to this problem? I cant imagine I am the only one with this problem. It also prevent me from running the client without worrying all the time about getting my connection taken away.
I now have blocked all incoming and outgoing traffic on port 6667 on my pc but I am not sure if bitcoin is working anymore. Is there a solution to this problem? I cant imagine I am the only one with this problem. It also prevent me from running the client without worrying all the time about getting my connection taken away.
Wouldn't all this create partitions of the network?
If I bootstrap and randomize into #bitcoin00, the peers there will only know about themselves, no?
Not if 10k clients try to get in 100 channels. If I bootstrap and randomize into #bitcoin00, the peers there will only know about themselves, no?
Wouldn't all this create partitions of the network?
If I bootstrap and randomize into #bitcoin00, the peers there will only know about themselves, no?
If I bootstrap and randomize into #bitcoin00, the peers there will only know about themselves, no?
DNS does not completely replace IRC, as its database can only be updated by the maintainer, not by everyone.
There's not much difference between these two, as a channel operator can ban/filter addresses and an IRCop can alter the server to return basically anything. For both you need to trust the maintainer not to tamper with the service.
If you want the clients to dynamically add their addresses to the bootstrapping service, you can do this with DNS, too. E.g. set up a DNS server that accepts DNS UPDATE (RFC2136) to add new records (obviously deny delete attempts and purge outdated entries from time to time). Or set up a tiny UDP update service additionally to DNS where clients can submit their address to the database.
Here's my proposal for how a better DNS bootstrapping mechanism could work.
Each client could resolve a special dns name such as
u5MGeZm2ktRwMNV.bootstrap.ve
where u5MGeZm2ktRwMNV is the same as the nickname used on IRC and encodes the host/port of the querying client.
The DNS server in response to this query would reply with a list of some number of verified bootstrap nodes. Rather than returning a simple DNS A record, the DNS server could reply with an SRV record specifying the port number as well as the address.
The server would then add u5MGeZm2ktRwMNV to a queue of nodes to be verified and subsequently it would appear as a reply to someone else's request. Perhaps if I have time I'll hack up an implementation of this.
DNS does not completely replace IRC, as its database can only be updated by the maintainer, not by everyone.
There's not much difference between these two, as a channel operator can ban/filter addresses and an IRCop can alter the server to return basically anything. For both you need to trust the maintainer not to tamper with the service.
If you want the clients to dynamically add their addresses to the bootstrapping service, you can do this with DNS, too. E.g. set up a DNS server that accepts DNS UPDATE (RFC2136) to add new records (obviously deny delete attempts and purge outdated entries from time to time). Or set up a tiny UDP update service additionally to DNS where clients can submit their address to the database.
DNS is a step forward in speed but also a step back in functionality.
Encoded in the IRC nicks is the port the peer is listening on. The DNS peer lookup has no way to do that the moment.
This means DNS discovery can only use the standard port which makes blocking peer bootstrapping much easier.
Not a big issue right now but it does need to be addressed at some point.
Encoded in the IRC nicks is the port the peer is listening on. The DNS peer lookup has no way to do that the moment.
This means DNS discovery can only use the standard port which makes blocking peer bootstrapping much easier.
Not a big issue right now but it does need to be addressed at some point.
You could ask for TXT records which store addresses in the same format that are used for IRC nicknames.
I haven't been having very good luck with the random IRC channels. Each of the random channels joined didn't have enough other clients attached. Eventually, I just modified bitcoind to connect to good old #bitcoin instead, and now everything is peachy. Perhaps the client should join multiple channels until enough folks have upgraded to the random channel-using clients?
It will be fine once the build is actually released and people start using it.. right now it's only the early adopters who are mostly already bootstrapped.
I haven't been having very good luck with the random IRC channels. Each of the random channels joined didn't have enough other clients attached. Eventually, I just modified bitcoind to connect to good old #bitcoin instead, and now everything is peachy. Perhaps the client should join multiple channels until enough folks have upgraded to the random channel-using clients?
DNS does not completely replace IRC, as its database can only be updated by the maintainer, not by everyone.
However, nodes also pass known addresses (including port, even with IPv6 support) to eachother. So DNS bootstrapping is just bootstrapping, finding *some* node, that knows other accessible nodes.
However, nodes also pass known addresses (including port, even with IPv6 support) to eachother. So DNS bootstrapping is just bootstrapping, finding *some* node, that knows other accessible nodes.
DNS is a step forward in speed but also a step back in functionality.
Encoded in the IRC nicks is the port the peer is listening on. The DNS peer lookup has no way to do that the moment.
This means DNS discovery can only use the standard port which makes blocking peer bootstrapping much easier.
Not a big issue right now but it does need to be addressed at some point.
Encoded in the IRC nicks is the port the peer is listening on. The DNS peer lookup has no way to do that the moment.
This means DNS discovery can only use the standard port which makes blocking peer bootstrapping much easier.
Not a big issue right now but it does need to be addressed at some point.
Yeah, DNSSeed will work fine I guess.
what about the proposal to use bittorrent trackers to find other peers?
see http://forum.bitcoin.org/index.php?topic=84.msg119872#msg119872
see http://forum.bitcoin.org/index.php?topic=84.msg119872#msg119872
Bittorrent trackers require a DNS lookup... at which point you might as well just use -dnsseed
Quote
clients can also specify the port they listen on
IRC is just for bootstrapping. Once you get at least one valid node, you connect and exchange peer addresses. The bitcoin peer exchange includes listen port.
* We use and monitor IRC and will keep an eye on the #bitcoinXX channels. The channel modes will be locked to a reasonable normal setting like #bitcoin is today.
Hmm. Needs more +m on #bitcoinXX channel, also do 'auto +m' on #bitcoinTEST. Not sure if it is possible but auto de-OP on #bitcoinXX join would also be nice.// CD-RW
Thanks laszlo, I didn't realize LFnet was so customized for Bitcoin.
what about the proposal to use bittorrent trackers to find other peers?
see http://forum.bitcoin.org/index.php?topic=84.msg119872#msg119872
clients can also specify the port they listen on
see http://forum.bitcoin.org/index.php?topic=84.msg119872#msg119872
clients can also specify the port they listen on
Quote
Couldn't you in theory hijack almost the entire network?
No, it wouldn't make much difference if the IRC network was compromised.
It is just used to get a list of hostnames to try to connect to, but you only need to connect to one real node in order to be able to receive the majority block chain. It is just one of many methods used to find other nodes - the address messages broadcast on the bitcoin network are the primary means, and once you've been connected to the network the client keeps a local cache of the addresses it has seen. The ones it sees on IRC are just added to the list.
You'd still be able to hijack new users
That would be true of any bootstrapping mechanism you can think of. At least with IRC it's somewhat transparent in that people can log in and see what's going on.. I don't really see any way around this though..
Also, users would probably notice that they weren't on the 'real' bitcoin network since they wouldn't be receiving any payments made to them or be able to send payments and also if they ever connect to a single real node by any of the bootstrapping mechanisms then they'd 'break out' of the illusion.
Connecting to a real node by what other mechanism?
This is why multiple mechanisms are a good thing
Infact, there's really very little motivation to 'hijack' a new user.. all you can really do is prevent them from communicating with other bitcoin users.. you can't steal their money or intercept their transactions.. all you could do it stop them from connecting to the network.. which they would probably notice and be able to work around. I guess you could force them to work on your block chain, but since mining is now disabled in the main client anyway that is no-longer true either.
Jump to: