Re: [Bitcoin-development] network disruption as a service and proof of local storage
Basically the problem with that is that someone could setup a single full node that has the blockchain and can answer those challenges and then a bunch of other non-full nodes that just proxy any such challenges to the single full node. Rob On 2015-03-26 23:04, Matt Whitlock wrote: Maybe I'm overlooking something, but I've been watching this thread with increasing skepticism at the complexity of the offered solution. I don't understand why it needs to be so complex. I'd like to offer an alternative for your consideration... Challenge: Send me: SHA256(SHA256(concatenation of N pseudo-randomly selected bytes from the block chain)). Choose N such that it would be infeasible for the responding node to fetch all of the needed blocks in a short amount of time. In other words, assume that a node can seek to a given byte in a block stored on local disk much faster than it can download the entire block from a remote peer. This is almost certainly a safe assumption. For example, choose N = 1024. Then the proving node needs to perform 1024 random reads from local disk. On spinning media, this is likely to take somewhere on the order of 15 seconds. Assuming blocks are averaging 500 KiB each, then 1024 blocks would comprise 500 MiB of data. Can 500 MiB be downloaded in 15 seconds? This data transfer rate is 280 Mbps. Almost certainly not possible. And if it is, just increase N. The challenge also becomes more difficult as average block size increases. This challenge-response protocol relies on the lack of a partial getdata command in the Bitcoin protocol: a node cannot ask for only part of a block; it must ask for an entire block. Furthermore, nodes could ban other nodes for making too many random requests for blocks. On Thursday, 26 March 2015, at 7:09 pm, Sergio Lerner wrote: If I understand correctly, transforming raw blocks to keyed blocks takes 512x longer than transforming keyed blocks back to raw. The key is public, like the IP, or some other value which perhaps changes less frequently. Yes. I was thinking that the IP could be part of a first layer of encryption done to the blockchain data prior to the asymetric operation. That way the asymmetric operation can be the same for all users (no different primers for different IPs, and then the verifiers does not have to verify that a particular p is actually a pseudo-prime suitable for P.H. ) and the public exponent can be just 3. Two protocols can be performed to prove local possession: 1. (prover and verifier pay a small cost) The verifier sends a seed to derive some n random indexes, and the prover must respond with the hash of the decrypted blocks within a certain time bound. Suppose that decryption of n blocks take 100 msec (+-100 msec of network jitter). Then an attacker must have a computer 50 faster to be able to consistently cheat. The last 50 blocks should not be part of the list to allow nodes to catch-up and encrypt the blocks in background. Can you clarify, the prover is hashing random blocks of *decrypted*, as-in raw, blockchain data? What does this prove other than, perhaps, fast random IO of the blockchain? (which is useful in its own right, e.g. as a way to ensure only full-node IO-bound mining if baked into the PoW) How is the verifier validating the response without possession of the full blockchain? You're right, It is incorrect. Not the decrypted blocks must be sent, but the encrypted blocks. There correct protocol is this: 1. (prover and verifier pay a small cost) The verifier sends a seed to derive some n random indexes, and the prover must respond with the the encrypted blocks within a certain time bound. The verifier decrypts those blocks to check if they are part of the block-chain. But then there is this improvement which allows the verifier do detect non full-nodes with much less computation: 3. (prover pays a small cost, verifier smaller cost) The verifier asks the prover to send a Merkle tree root of hashes of encrypted blocks with N indexes selected by a psudo-random function seeded by a challenge value, where each encrypted-block is previously prefixed with the seed before being hashed (e.g. N=100). The verifier receives the Markle Root and performs a statistical test on the received information. From the N hashes blocks, it chooses M N (e.g. M = 20), and asks the proved for the blocks at these indexes. The prover sends the blocks, the verifier validates the blocks by decrypting them and also verifies that the Merkle tree was well constructed for those block nodes. This proves with high probability that the Merkle tree was built on-the-fly and specifically for this challenge-response protocol. I also wonder about the effect of spinning disk versus SSD. Seek time for 1,000 random reads is either nearly zero or dominating depending on the two modes. I
Re: [Bitcoin-development] network disruption as a service and proof of local storage
The main motivation is to try and stop a single entity running lots of nodes in order to harvest transaction origin IPs. That's what's behind this. Probably the efforts are a waste of time.. if someone has to keep a few hundred copies of the blockchain around in order to keep IP specific precomputed data around for all the IPs they listen on then they'll just buy a handful of 5TB HDs and call it a day.. still some of the ideas proposed are quite interesting and might not have much downside. Rob On 2015-03-27 15:16, Matt Whitlock wrote: I agree that someone could do this, but why is that a problem? Isn't the goal of this exercise to ensure more full nodes on the network? In order to be able to answer the challenges, an entity would need to be running a full node somewhere. Thus, they have contributed at least one additional full node to the network. I could certainly see a case for a company to host hundreds of lightweight (e.g., EC2) servers all backed by a single copy of the block chain. Why force every single machine to have its own copy? All you really need to require is that each agency/participant have its own copy. On Friday, 27 March 2015, at 2:32 pm, Robert McKay wrote: Basically the problem with that is that someone could setup a single full node that has the blockchain and can answer those challenges and then a bunch of other non-full nodes that just proxy any such challenges to the single full node. Rob On 2015-03-26 23:04, Matt Whitlock wrote: Maybe I'm overlooking something, but I've been watching this thread with increasing skepticism at the complexity of the offered solution. I don't understand why it needs to be so complex. I'd like to offer an alternative for your consideration... Challenge: Send me: SHA256(SHA256(concatenation of N pseudo-randomly selected bytes from the block chain)). Choose N such that it would be infeasible for the responding node to fetch all of the needed blocks in a short amount of time. In other words, assume that a node can seek to a given byte in a block stored on local disk much faster than it can download the entire block from a remote peer. This is almost certainly a safe assumption. For example, choose N = 1024. Then the proving node needs to perform 1024 random reads from local disk. On spinning media, this is likely to take somewhere on the order of 15 seconds. Assuming blocks are averaging 500 KiB each, then 1024 blocks would comprise 500 MiB of data. Can 500 MiB be downloaded in 15 seconds? This data transfer rate is 280 Mbps. Almost certainly not possible. And if it is, just increase N. The challenge also becomes more difficult as average block size increases. This challenge-response protocol relies on the lack of a partial getdata command in the Bitcoin protocol: a node cannot ask for only part of a block; it must ask for an entire block. Furthermore, nodes could ban other nodes for making too many random requests for blocks. On Thursday, 26 March 2015, at 7:09 pm, Sergio Lerner wrote: If I understand correctly, transforming raw blocks to keyed blocks takes 512x longer than transforming keyed blocks back to raw. The key is public, like the IP, or some other value which perhaps changes less frequently. Yes. I was thinking that the IP could be part of a first layer of encryption done to the blockchain data prior to the asymetric operation. That way the asymmetric operation can be the same for all users (no different primers for different IPs, and then the verifiers does not have to verify that a particular p is actually a pseudo-prime suitable for P.H. ) and the public exponent can be just 3. Two protocols can be performed to prove local possession: 1. (prover and verifier pay a small cost) The verifier sends a seed to derive some n random indexes, and the prover must respond with the hash of the decrypted blocks within a certain time bound. Suppose that decryption of n blocks take 100 msec (+-100 msec of network jitter). Then an attacker must have a computer 50 faster to be able to consistently cheat. The last 50 blocks should not be part of the list to allow nodes to catch-up and encrypt the blocks in background. Can you clarify, the prover is hashing random blocks of *decrypted*, as-in raw, blockchain data? What does this prove other than, perhaps, fast random IO of the blockchain? (which is useful in its own right, e.g. as a way to ensure only full-node IO-bound mining if baked into the PoW) How is the verifier validating the response without possession of the full blockchain? You're right, It is incorrect. Not the decrypted blocks must be sent, but the encrypted blocks. There correct protocol is this: 1. (prover and verifier pay a small cost) The verifier sends a seed
Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic
On Mon, 28 Jul 2014 07:28:15 -0400, Peter Todd wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I've got a bitcoin-only exit running myself and right now there is absolutely no traffic leaving it. If the traffic coming from that node was legit I'd expect some to be exiting my node too. Multiple people have confirmed the node is connected to an abnormally large % of the Bitcoin network. Looks like a Sybil attack to me, trying to hide behind a Tor exit node for plausible deniability. I don't think Sybil attack is the right term for this.. there is only one IP address.. one identity. I'm not even sure that this behaviour can be considered abuse.. it's pretty much following the rules and maybe even improving the transaction and block propagation. As far as monitoring transaction origins someone could do that using lots of different IPs instead of just one (more like an actual Sybil attack rather than this non-Sybil attack).. and noone would be making a fuss (and imo, probably someone does do that too as it would be useful to capture a larger number of inbound connections). Rob -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic
Here's a packet dump of a connected client: http://wari.mckay.com/~rm/unknown.tcpdump Doesn't seem particularly abusive.. only one connection, not doing much traffic. I don't have any easy way to deserialize this and see if it's doing anything unusual but it's there if someone wants to have a go. Rob On Sun, 27 Jul 2014 22:49:11 -0400, Michael Wozniak wrote: It’s in my logs: 2014-07-28 02:00:24 receive version message: /Satoshi:0.9.2/: version 70002, blocks=302684, us=**:8333, them=0.0.0.0:0, peer=5.9.93.101:33928 On Jul 27, 2014, at 10:45 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Sun, Jul 27, 2014 at 7:40 PM, Peter Todd p...@petertodd.org wrote: Anyway, just goes to show that we need to implement better incoming connection limiting. gmaxwell has a good scheme with interactive proof-of-memory - where's your latest writeup? Or its a complete snipe hunt, I'm unable to find any nodes with it connected to them. Does anyone here have any? Last discussion on the measures for anti-global-resource-consumption was at https://bitcointalk.org/index.php?topic=310323.0 but it hasn't seemed to be a huge issue such that adding more protocol surface area was justified. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again
Hi Alex, I think the problem is with my suggestion to use bind forwarding.. basically bind is stripping off the authorative answer bit in the reply.. this causes the recursor to go into a loop chasing the authority server which again returns a non-authoritve answer with itself as the authority again. I'm not sure if this can be fixed without hacking the bind src, so maybe it wasn't such a great suggestion in the first place. Basically I think if bind was returning authorative answers it would work, but I can't see any way to make that happen in the bind configuration. Rob On Fri, 30 May 2014 14:19:05 +0100, Alex Kotenko wrote: Hi Peter Ive setup DNS seeds myself a week ago, at testnet-seed.alexykot.me [6] and bitcoin-seed.alexykot.me [7], but there is a problem with DNS settings that we with Andreas couldnt sort out quickly. The problem itself is that I can reach my nameserver and get dnsseed response if I query it directly with dig @node.alexykot.me [8] testnet-seed.alexykot.me [9] dig @node.alexykot.me [10] bitcoin-seed.alexykot.me [11] But when I try nslookup testnet-seed.alexykot.me [12] - it fails. I guess the problem is in my DNS settings but I cant figure out what is it. S o could you share how you configured DNS for your seed to help me debug mine ? Best regards, Alex Kotenko 2014-05-30 10:43 GMT+01:00 Peter Todd : -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27 May 2014 02:19:39 GMT+03:00, Andreas Schildbach wrote: Hey, really sorry I dont have the time to fix this issue, been travelling for a few weeks for my consulting job. If you want to step up and volunteer please feel free. Im already volunteering. At least I dont get paid for my efforts in debugging the seed infrastructure. I meant running a seed yourself. Note that Ive only received funds to cover expenses and a trivial amount on top to cover some time - about one and a half hours at my usual rates. Gavin: Speaking of, given it looks like my work will be frequently keeping me out of country and unable to provide any more than a best effort attempt at running a seed, Id like to give back the grant funds for doing so. Email me privately with an address to send them too. I have no plans to take it down, however the expectations users have for it arent something I can provide. Can you verify if your copy of the seeder contains the commit 8dcc006e6256cb746c2b025daf3df41baa26353e ? It fixed a bug that has exactly the symptoms we currently see. I wonder if the restart of your server actually changed/fixed anything. If you got a SERVFAIL this may be because you were traveling through parts of the world that cant reach your server. Did you actually try at home, before the restart? I checked via the same proxy both times; I believe the endpoint is located in Europe. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJTiFKwMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhQFCB/4jypD+xzKVp6fqRUxu v22Rc6PeCbeaPYKmdNu0LbY1G5spB8C8ooaZX6z0Ib/CYobzDPJ+rJNB+c1Fna4N 1IdH7ZsrX0GFaEn7Grnp7D2rtOXGZV+1XGFAateIA/caQ9+rJfqkHLuvOI0Fh+Ua /m857rxUNtA1kObLFS7gfhi2gwXGO6KQ3muS3462hXVVc9j7DhOWQQwJba5PL+Je Eob4WtnF2gVFlCEWevxvflF7j4lW9I/S81yZQDnNW9ATF2mfZVqo26sB0yL6Tm4l KgdKx7+w3khv6QfW9Ilx0Ov3Ml2ZMRhBimpbnENbW4jfklsuRQcM0yx6vXS/lIMz LO5s =Up3N -END PGP SIGNATURE- -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download [2] http://p.sf.net/sfu/restlet [3] ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net [4] https://lists.sourceforge.net/lists/listinfo/bitcoin-development [5] Links: -- [1] mailto:andr...@schildbach.de [2] http://www.restlet.com/download [3] http://p.sf.net/sfu/restlet [4] mailto:Bitcoin-development@lists.sourceforge.net [5] https://lists.sourceforge.net/lists/listinfo/bitcoin-development [6] http://testnet-seed.alexykot.me [7] http://bitcoin-seed.alexykot.me [8] http://node.alexykot.me [9] http://testnet-seed.alexykot.me [10] http://alexykot.me [11] http://bitcoin-seed.alexykot.me [12] http://testnet-seed.alexykot.me [13] mailto:p...@petertodd.org -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again
No, I don't think so. The problem is the 'aa' flag is missing (see the 'flags' section in dig). Perhaps if you could suppress the authority records the recursor would give up and just accept the non-authorative answer, but that isn't a good solution even if it might work for some resolvers. Rob On Fri, 30 May 2014 15:13:36 +0100, Alex Kotenko wrote: Hmm, you might be right, as queries dig @node.alexykot.me [8] testnet-seed.alexykot.me [9] and dig @node.alexykot.me [10] -p 18353 testnet-seed.alexykot.me [11] are giving different authority sections. Hmm, but if I setup custom SOA record for it - it should work, right? What SOA name should it be actually, assuming that NS record for testnet-seed.alexykot.me [12] is pointing at alexykot.me [13]? Best regards, Alex Kotenko 2014-05-30 14:41 GMT+01:00 Robert McKay : Hi Alex, I think the problem is with my suggestion to use bind forwarding.. basically bind is stripping off the authorative answer bit in the reply.. this causes the recursor to go into a loop chasing the authority server which again returns a non-authoritve answer with itself as the authority again. Im not sure if this can be fixed without hacking the bind src, so maybe it wasnt such a great suggestion in the first place. Basically I think if bind was returning authorative answers it would work, but I cant see any way to make that happen in the bind configuration. Rob On Fri, 30 May 2014 14:19:05 +0100, Alex Kotenko wrote: Hi Peter Ive setup DNS seeds myself a week ago, at testnet-seed.alexykot.me [1] [6] and bitcoin-seed.alexykot.me [2] [7], but there is a problem with DNS settings that we with Andreas couldnt sort out quickly. The problem itself is that I can reach my nameserver and get dnsseed response if I query it directly with dig @node.alexykot.me [3] [8] testnet-seed.alexykot.me [4] [9] dig @node.alexykot.me [5] [10] bitcoin-seed.alexykot.me [6] [11] But when I try nslookup testnet-seed.alexykot.me [7] [12] - it fails. I guess the problem is in my DNS settings but I cant figure out what is it. S o could you share how you configured DNS for your seed to help me debug mine ? Best regards, Alex Kotenko Links: -- [1] http://testnet-seed.alexykot.me [2] http://bitcoin-seed.alexykot.me [3] http://node.alexykot.me [4] http://testnet-seed.alexykot.me [5] http://node.alexykot.me [6] http://bitcoin-seed.alexykot.me [7] http://testnet-seed.alexykot.me [8] http://node.alexykot.me/ [9] http://testnet-seed.alexykot.me/ [10] http://node.alexykot.me/ [11] http://testnet-seed.alexykot.me/ [12] http://testnet-seed.alexykot.me [13] http://alexykot.me [14] mailto:rob...@mckay.com -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again
A simple hack would be to crontab up a couple of dig scripts that every minute 'dig' (dig's output is in bind zonefile format) the bitcoin-seed and write the results to two zonefiles that bind can then serve. Basically dig @127.0.0.1 -p 5353 zonefile1.zone dig @127.0.0.1 -p 5354 zonefile2.zone pkill -HUP named Ugly, but should work. Rob On Fri, 30 May 2014 17:40:06 +0200, Andreas Schildbach wrote: I maybe have made this suggestion in the past, but why don't we teach the seeder (or maybe even plain bitcoind) how to write a zone file and then use matured DNS servers to serve this zone? I admit I never ran my own DNS so I'm not sure if that can work -- but to me it sounds like the easiest approach plus everyone can just use stock server software. On 05/30/2014 05:24 PM, Pieter Wuille wrote: I don't think it would be too hard to add support for a option to the seeder for non-matching requests, forward to other DNS server at IP:PORT, so you could cascade them. On Fri, May 30, 2014 at 4:51 PM, Robert McKay rob...@mckay.com wrote: No, I don't think so. The problem is the 'aa' flag is missing (see the 'flags' section in dig). Perhaps if you could suppress the authority records the recursor would give up and just accept the non-authorative answer, but that isn't a good solution even if it might work for some resolvers. Rob On Fri, 30 May 2014 15:13:36 +0100, Alex Kotenko wrote: Hmm, you might be right, as queries dig @node.alexykot.me [8] testnet-seed.alexykot.me [9] and dig @node.alexykot.me [10] -p 18353 testnet-seed.alexykot.me [11] are giving different authority sections. Hmm, but if I setup custom SOA record for it - it should work, right? What SOA name should it be actually, assuming that NS record for testnet-seed.alexykot.me [12] is pointing at alexykot.me [13]? Best regards, Alex Kotenko 2014-05-30 14:41 GMT+01:00 Robert McKay : Hi Alex, I think the problem is with my suggestion to use bind forwarding.. basically bind is stripping off the authorative answer bit in the reply.. this causes the recursor to go into a loop chasing the authority server which again returns a non-authoritve answer with itself as the authority again. Im not sure if this can be fixed without hacking the bind src, so maybe it wasnt such a great suggestion in the first place. Basically I think if bind was returning authorative answers it would work, but I cant see any way to make that happen in the bind configuration. Rob On Fri, 30 May 2014 14:19:05 +0100, Alex Kotenko wrote: Hi Peter Ive setup DNS seeds myself a week ago, at testnet-seed.alexykot.me [1] [6] and bitcoin-seed.alexykot.me [2] [7], but there is a problem with DNS settings that we with Andreas couldnt sort out quickly. The problem itself is that I can reach my nameserver and get dnsseed response if I query it directly with dig @node.alexykot.me [3] [8] testnet-seed.alexykot.me [4] [9] dig @node.alexykot.me [5] [10] bitcoin-seed.alexykot.me [6] [11] But when I try nslookup testnet-seed.alexykot.me [7] [12] - it fails. I guess the problem is in my DNS settings but I cant figure out what is it. S o could you share how you configured DNS for your seed to help me debug mine ? Best regards, Alex Kotenko Links: -- [1] http://testnet-seed.alexykot.me [2] http://bitcoin-seed.alexykot.me [3] http://node.alexykot.me [4] http://testnet-seed.alexykot.me [5] http://node.alexykot.me [6] http://bitcoin-seed.alexykot.me [7] http://testnet-seed.alexykot.me [8] http://node.alexykot.me/ [9] http://testnet-seed.alexykot.me/ [10] http://node.alexykot.me/ [11] http://testnet-seed.alexykot.me/ [12] http://testnet-seed.alexykot.me [13] http://alexykot.me [14] mailto:rob...@mckay.com -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net
Re: [Bitcoin-development] DNS seeds unstable
It should be possible to configure bind as a DNS forwarder.. this can be done in a zone context.. then you can forward the different zones to different dnsseed daemons running on different non-public IPs or two different ports on the same IP (or on one single non-public IP since there's really no reason to expose the dnsseed directly daemon at all). Rob On Mon, 19 May 2014 21:14:32 +0100, Alex Kotenko wrote: Hmm, Ive mostly setup whats promised, testing DNS seeds now. There is one problem I see that I cant really solve myself. This dnsseed daemon cannot serve more than one name at once, which means that I cannot serve testnet and mainnet seeds off one daemon instance which means I need to buy two IP addresses for it. Thats unfortunate as it needs much more spendings from me to operate, second IP address will cost nearly as much as the server itself. Can anybody help with this? I cannot into C++ to fix that myself. Best regards, Alex Kotenko 2014-05-17 13:39 GMT+01:00 Andreas Schildbach : On 05/17/2014 02:02 PM, Alex Kotenko wrote: So, my understanding is that atm we have no working DNS seeds at the testnet3, right? There are two DNS seeds known, of which one is unreachable atm, and another one is giving just one IP address, which is also a dead node. Yes, thats my understanding too. If Ill start a DNS seed of my own and make sure it works well, will this help? Yes, definately. Ive found this DNS seeder daemon , and it seems to be exactly what I need to run a DNS seeder myself. Afaik this is what most of the other seeds are using, yes. So if my understanding is correct, Ill setup a DNS seeds for mainnet and for testnet at bitcoin-seed.alexykot.me [2] and testnet-seed.alexykot.me [4] , and also a well connected nodes for mainnet and testnet on the same server. Is this a good plan? Will this all help? Sound great! Let me know if youve got something to test. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs [6] ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net [7] https://lists.sourceforge.net/lists/listinfo/bitcoin-development [8] Links: -- [1] https://github.com/sipa/bitcoin-seeder [2] http://bitcoin-seed.alexykot.me [3] http://bitcoin-seed.alexykot.me [4] http://testnet-seed.alexykot.me [5] http://testnet-seed.alexykot.me [6] http://p.sf.net/sfu/SauceLabs [7] mailto:Bitcoin-development@lists.sourceforge.net [8] https://lists.sourceforge.net/lists/listinfo/bitcoin-development [9] mailto:andr...@schildbach.de -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
On Mon, 19 May 2014 19:49:52 -0400, Jeff Garzik wrote: On Mon, May 19, 2014 at 4:36 PM, Robert McKay rob...@mckay.com wrote: It should be possible to configure bind as a DNS forwarder.. this can be done in a zone context.. then you can forward the different zones to different dnsseed daemons running on different non-public IPs or two different ports on the same IP (or on one single non-public IP since there's really no reason to expose the dnsseed directly daemon at all). Quite the opposite. dnsseed data rotates through a lot of addresses if available. Using the bind/zone-xfer system would result in fewer total addresses going through to the clients, thanks to the addition of caching levels that the bind/zone-xfer system brings. That said, if the choice is between no-service and bind, bind it is ;p Setting it up as a zone forwarder causes each request to go through to the dnsseed backend for each request. Rob -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
On Tue, 20 May 2014 01:44:29 +0100, Robert McKay wrote: On Mon, 19 May 2014 19:49:52 -0400, Jeff Garzik wrote: On Mon, May 19, 2014 at 4:36 PM, Robert McKay rob...@mckay.com wrote: It should be possible to configure bind as a DNS forwarder.. this can be done in a zone context.. then you can forward the different zones to different dnsseed daemons running on different non-public IPs or two different ports on the same IP (or on one single non-public IP since there's really no reason to expose the dnsseed directly daemon at all). Quite the opposite. dnsseed data rotates through a lot of addresses if available. Using the bind/zone-xfer system would result in fewer total addresses going through to the clients, thanks to the addition of caching levels that the bind/zone-xfer system brings. That said, if the choice is between no-service and bind, bind it is ;p Setting it up as a zone forwarder causes each request to go through to the dnsseed backend for each request. This stackoverflow describes a similar situation; http://stackoverflow.com/questions/15338232/how-to-forward-a-subzone you can additionally specify the port to forward too; http://www.zytrax.com/books/dns/ch7/queries.html#forwarders it should be possible to forward to different ports on 127.0.0.1 for each dnsseed instance. Rob -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor / SPV
On Wed, 15 Jan 2014 23:51:21 +0100, Mike Hearn wrote: The goal of all that is that we get to keep our existing IPv4 based anti-sybil heuristics, so we can’t possibly make anything worse, only better. Plus, we’ve now set things up so in future if/when we come up with a better anti-sybil system based on anonymous identities or other fancy crypto, we can take out the “connect via clearnet” step and go straight to using hidden services with only a very small set of code changes and no new protocol work. I think it might be ok to use proof-of-stake on as an anti-sybil scheme on tor.. people would obviously not want to associate their wallet with their IP address, but is there any harm in associating it with a (temporary) tor service id (especially one that isn't used for anything other than relaying bitcoin transactions)? If each node you connect too can sign some challenge with a key that controls some BTC (and your client node verifies that the funds are different) then that might be useful.. even if it were only a small 0.01BTC stake that would be similar to the cost of obtaining another IP through a cheap VPS or VPN and significantly higher than the cost to an attacker who is able to MITM everything and operate on any IP anyway. Rob -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On Sun, 8 Dec 2013 13:14:44 -0800, Gregory Maxwell wrote: On Sun, Dec 8, 2013 at 1:07 PM, Drak d...@zikula.org wrote: Simple verification relies on being able to answer the email sent to the person in the whois records, or standard admin/webmaster@ addresses to prove ownership of the domain Godaddy and many other CA's are verified from nothing other than a http fetch, no email involved. It's just as easy to steal emails via a BGP or DNS redirect anyway.. you could even take over the actual domain at the registry level by stealing a password reset via BGP or DNS redirect and actually many registries will hand over control of a domain by faxing them a forged driving license in the owner's name anyway so it doesn't even really need to be a particularly sophisticated attacker. Once you have registry control of the domain it's easy enough to get an SSL cert too, probably even an 'extended validation' one. When Afghanistan was taken over the entire .af TLD was probably transferred using a forged fax to ICANN (http://web.archive.org/web/20041017031020/http://www.iana.org/cctld/af/razeeq-letter-13aug02.pdf) but I guess that's a little different :p Rob -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A mining pool at 46%
On Fri, 5 Apr 2013 11:48:51 +0200, Mike Hearn wrote: However, youre somewhat right in the sense that its a self-defeating attack. If the pool owner went bad, he could pull it off once, but the act of doing so would leave a permanent record and many of the people mining on his pool would leave. As he doesnt own the actual mining hardware, he then wouldnt be able to do it again. Unless all the miners are monitoring the work they do for their pools and the actual miners that found the blocks noticed (unlikely) - the only way anyone knows which pool did anything is the source IP that first disseminates the new block. Also since it's unlikely that both of the doublespend blocks would be found by the same end miner, neither of them would know that the pool operator was responsible even if they were monitoring their work. There's nothing stopping the pool owner from channeling the doublespend blocks through some other previously unknown IP, so I don't think they would suffer any reputational damage from doing this repeatidly. Robert -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
