<unnamed>

Public Key

npub1t6suh64e65qzzjtthffl6sa3cagp6k9usnx4qev4jsjzf7xud8psdhe2py

Profile Code

nprofile1qqs9agwta2ua2qppf94m55lagwcuw5qatz7gfn2svk2egfpylrwxnscpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmctffmg4

Publishing to

nostr.wine

relay.damus.io

Last Notes

2023-06-07 15:21:27 UTC

- 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 UTC

- 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 UTC

- 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 15:10:32 UTC

- reply

📅 Original date posted:2013-12-08
📝 Original message:On Sun, 8 Dec 2013 13:14:44 -0800, Gregory Maxwell wrote:
> On Sun, Dec 8, 2013 at 1:07 PM, Drak <drak at 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

2023-06-07 10:09:26 UTC

- 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 01:59:47 UTC

- 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>