Robert McKay [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-07-01 to 2015-03-27
💬 Posted a total of 16 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:32:03

- reply

📅 Original date posted:2015-03-27
📝 Original message: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
>> >> 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 wonder if a sequential read from a random
>> >> index is
>> >> > a possible trade-off,; it doesn't prove possession of the whole
>> >> chain
>> >> > nearly as well, but at least iowait converges significantly.
>> Then
>> >> > again, that presupposes a specific ordering on disk which might
>> >> not
>> >> > exist. In X years it will all be solid-state, so eventually
>> it's
>> >> moot.
>> >> >
>> >> Good idea.
>> >>
>> >> Also we don't need that every node implements the protocol, but
>> only
>> >> nodes that want to prove full-node-ness, such as the ones which
>> want
>> >> to
>> >> receive bitnodes subsidy.
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Dive into the World of Parallel Programming The Go Parallel
>> Website,
>> > sponsored
>> > by Intel and developed in partnership with Slashdot Media, is your
>> > hub for all
>> > things parallel software development, from weekly thought
>> leadership
>> > blogs to
>> > news, videos, case studies, tutorials and more. Take a look and
>> join
>> > the
>> > conversation now. http://goparallel.sourceforge.net/
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your
>> hub for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join
>> the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:32:02

- reply

📅 Original date posted:2015-03-27
📝 Original message: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 wonder if a sequential read from a random
>> index is
>> > a possible trade-off,; it doesn't prove possession of the whole
>> chain
>> > nearly as well, but at least iowait converges significantly. Then
>> > again, that presupposes a specific ordering on disk which might
>> not
>> > exist. In X years it will all be solid-state, so eventually it's
>> moot.
>> >
>> Good idea.
>>
>> Also we don't need that every node implements the protocol, but only
>> nodes that want to prove full-node-ness, such as the ones which want
>> to
>> receive bitnodes subsidy.
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all
> things parallel software development, from weekly thought leadership
> blogs to
> news, videos, case studies, tutorials and more. Take a look and join
> the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:24:31

- reply

📅 Original date posted:2014-07-28
📝 Original message: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

2023-06-07 15:22:00

- reply

📅 Original date posted:2014-05-30
📝 Original message: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 at lists.sourceforge.net [4]
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> [5]
>
>
>
> Links:
> ------
> [1] mailto:andreas at schildbach.de
> [2] http://www.restlet.com/download
> [3] http://p.sf.net/sfu/restlet
> [4] mailto:Bitcoin-development at 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:pete at petertodd.org

2023-06-07 15:21:27

- reply

📅 Original date posted:2014-05-19
📝 Original message: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 <robert at 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

2023-06-07 15:21:26

- reply

📅 Original date posted:2014-05-19
📝 Original message: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 at 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 at lists.sourceforge.net
> [8] https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> [9] mailto:andreas at schildbach.de

2023-06-07 15:21:26

- reply

📅 Original date posted:2014-05-19
📝 Original message:On Mon, 19 May 2014 19:49:52 -0400, Jeff Garzik wrote:
> On Mon, May 19, 2014 at 4:36 PM, Robert McKay <robert at 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

2023-06-07 10:09:26

- reply

📅 Original date posted:2012-05-24
📝 Original message:On Thu, 24 May 2012 12:33:12 -0400, Jeff Garzik wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks. Even with satoshi's key observation -- hash a fixed
> 80-byte header, not the entire block -- some miners still find it
> easier to mine empty blocks, rather than watch the network for new
> transactions.
>
> Therefore I was wondering what people thought about a client
> implementation change:
>
> - Do not store or relay empty blocks, if time since last block <
> X
> (where X = 60 minutes, perhaps)
>
> or even stronger,
>
> - Ensure latest block includes at least X percent of mempool
> unconfirmed TXs
If miners wanted to continue mining empty blocks without bothering to
monitor the Tx pool they would just switch to stuffing the empty blocks
with a dummy transaction of their own to get round your new rules. They
could also spam them to the p2p network so that they end up in the
mempool if that were necessary. This would probably still be slightly
easier than 'doing it properly'.
Once the block reward halves in a few months time then receiving
transaction fees will probably become more important to the miner's
profit and loss calculations and they'll spend the extra time to
implement proper transaction processing. I suspect if we do nothing this
particular issue will go away. Perhaps it could be helped along by
publishing some example code to make it easier for them.
The ability to refuse transactions seems like an important part of the
game theory of transaction pricing. Miners are supposed to be able to
jack up transaction costs by declining to process no fee or too low fee
(in their opinion) transactions.. the counter balance is that they are
losing money by doing that and leaving more on the table for the next
miner to score a block.
I expect that in the future there will be other instances when people
complain that the miners are being 'unfair' and that the rules should be
changed in some way to lower transaction fees (ie: increase block size).
If block sizes are increased ever larger and miners aren't allowed to
refuse to process transactions it will get rid of the financial
motivation for mining and less mining will happen. We should be very
careful when making these kinds of changes.
Setting percentage quotas of stuff in the mempool sounds dangerous..
miners that hear about a block from a rival miner soon enough could
possibly DOS the mempool on the rest of the network to get the block
rejected. I think it should be legitimate not to publish a transaction
to the p2p network at all.. in the future there will probably be lots of
networks other than the p2p network.. right now we have the IPv6 network
and the IPv4 network.. in the future there could be many other protocols
and perhaps not all transactions will make it back to the old legacy
ipv4 p2p network or into the mempool of bitcoin nodes on that network..
but they should still be able to get into the block chain.
Rob

2023-06-07 02:06:13

- reply

📅 Original date posted:2011-07-16
🗒️ Summary of this message: Discussion about potentially moving the Bitcoin development project to a new URL due to issues with the current domain ownership.
📝 Original message:On 7/17/11, Jeff Garzik <jgarzik at exmulti.com> wrote:
> On Sat, Jul 16, 2011 at 9:16 PM, Douglas Huff <dhuff at jrbobdobbs.org> wrote:
>> I say just kill the forum.bitcoin.org DNS entry along with it.
>
> Hopefully sirius will do this when he moves forum.bitcoin.org to
> forum.bitcointalk.org.
>
> But sirius is the only one with keys to bitcoin.org DNS, so....
At the risk of making myself very unpopular, perhaps it's the
development project that should move to a new URL?
Rob

2023-06-07 01:59:47

- reply

📅 Original date posted:2011-07-01
🗒️ Summary of this message: Discussion on enabling UPnP in Bitcoin. Some are in favor of turning it on by default in the GUI, while others are concerned about security.
📝 Original message:On Fri, Jul 1, 2011 at 5:35 PM, <jan at uos.de> wrote:
> On Fri, Jul 01, 2011 at 11:06:56AM -0400, Gavin Andresen wrote:
> > > Not sure about OS differentiation, seems...wrong? Maybe disabled by
> > > default on bitcoind but on by default on bitcoin?
> >
> > OK. I mis-remembered the poll:
> > http://forum.bitcoin.org/index.php?topic=4392.0
> >
> > On by default 8 (20%)
> > Off by default 22 (55%)
> > On by default in the GUI, off by default in bitcoind 10 (25%)
>
> I just voted as well and now - with some extra votes in the meantime -
> it's 9 / 22 / 13. So exactly 50/50 between off (22) and some form of on
> (9 + 13).
>
> I'm in favor of turning it on by default in the GUI and leaving it off
> in bitcoind.
>
> I don't like UPnP much, I find it exemplifies exactly what is wrong with
> computer security today: Convenience trumps security almost every time.
>
> BUT: I don't think this is the moment to fight UPnP. It's the standard
> mechanism in use today to let a computer behind a NAT accept incoming
> connections. The user has already made the decision in regards to
> convenience over security. By enabling UPnP (or by buying a product that
> does this automatically) they are saying: I want it to "just work"
> instead of having fine-grained but more complicated control.
>
> Bitcoin is a P2P application and as such should use this
> mechanism. I think it's pretty clear that participating in a P2P network
> requires one to receive messages from other peers. At least no one seems
> to be concerned that Bitcoin (by default!) listens on port 8333. So I
> think it's only logical to extend that to work behind NATs as well
If bitcoin listened on IPv6 that might help for alot of people. Windows 7
users get a teredo IPv6 address (unless they disable it) when behind NAT on
IPv4. Take any win7 box and put it on a typical NAT /DSL setup this is what
happens. I think this might actually work for more users than have UPNP
support on their DSL gateways. teredo IPs aren't that stable though (they
change frequently) and they might tend to flood the address cache with stale
addresses.
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110701/195a339b/attachment.html>