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
>> wrote:
>>> It should be possible to configure bind as a DNS forwarder.. this
>>> can
>>> be done in a zone context.. then you can for
You would set it up as a forwarder, not as a zone transfer to bind. That
should proxy the request every time and only cache based on any TTL that’s set
in the response.
Here’s an example of how it could work:
https://planet.jboss.org/post/setting_up_a_forwarding_dns_server_or_dns_proxy_with_isc
On Mon, 19 May 2014 19:49:52 -0400, Jeff Garzik wrote:
> On Mon, May 19, 2014 at 4:36 PM, Robert McKay
> 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
On Mon, May 19, 2014 at 4:36 PM, Robert McKay 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 sam
A quick update on the project:
More reviews and feedback on the pull request are very welcome:
https://github.com/bitcoin/bitcoin.org/pull/393
This pull request will be merged on May 24th and hopefully will be
accurate as much as possible. Reporting any inaccuracy / mistake on the
pull request is
On Mon, May 19, 2014 at 5:09 PM, Mike Hearn wrote:
> Most companies (Google certainly included) have therefore banned their staff
> from reading patents,
Bitcoin is not Google though, and applying the same patent protocols
to Bitcoin as in Google is drawing a false equivalence between the
two. Go
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2014 11:07 PM, Gregory Maxwell wrote:
> I promise that if bad people show up with a sufficient pointy gun
> that I'll do whatever they tell me to do. I'll make bad proposals,
> submit backdoors, and argue with querulous folks on mailing lists,
On Mon, May 19, 2014 at 1:01 PM, Justus Ranvier wrote:
> YOU can make promises about YOUR future behavior. So can everyone else.
>
> The rest of the community can keep track of which developers will and
> will not make promises about what changes they will and will not
> attempt to implement in Bi
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
I’m not familiar with how the daemon works, however could you set up two
daemons listening local on different ports and with a separate daemon or normal
dns server that proxies incoming queries to either domain? I don’t know if
standard DNS servers would support that, or if you would need a cust
Well, it's possible theoretically, but will need another piece of custom
software that will understand DNS protocol and proxy it correctly based on
actual incoming DNS queries.
On 19 May 2014 21:22, "Michael Wozniak" wrote:
> I’m not familiar with how the daemon works, however could you set up tw
Hmm, I've mostly setup what's promised, testing DNS seeds now. There is one
problem I see that I can't 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2014 10:06 PM, Mike Hearn wrote:
> Sorry. I will never agree to the concept of a relevant idea so
> dangerous it cannot be discussed. That's medieval thinking. If you
> would like to create a parallel development forum where people have
> to s
Sorry. I will never agree to the concept of a relevant idea so dangerous it
cannot be discussed. That's medieval thinking. If you would like to create
a parallel development forum where people have to swear an oath not to
think bad thoughts, go right ahead and do so.
But I'm glad to see you correc
Okey dokey:
I hereby promise and solemnly swear on pain of atomic wedgie that I will
never ever work on or endorse any changes to the Bitcoin system that would
enable any person or group to confiscate, blacklist, or devalue any other
person or group's bitcoin.
RE: writing an RFC: go for it. I hav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2014 09:41 PM, Gavin Andresen wrote:
> Now I'm really confused.
>
> Why would Mike or I have the authority to write a "social contract"
> to promise anything about future-Bitcoin?
YOU can make promises about YOUR future behavior. So can ever
On Mon, May 19, 2014 at 2:20 PM, Justus Ranvier wrote:
>
> You and Gavin could do a lot better by working on a Bitcoin social
> contract - a promise of what features will *never* be added (or taken
> away) from Bitcoin, because despite what you say it's not acceptable
> to propose anything at all.
>
> Avoiding willfull infringement no longer requires paying off a
> patent attorney to get a freedom to operate review. This isn't to say
> that reading patents is always productive
That case raised the bar a bit, but the core problem remains - if you learn
about a patent you definitely violate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 May 2014 20:43:15 CEST, Gregory Maxwell wrote:
>There are other defensive approaches which are interesting than hoping
>to use patents as a counter attack: For one— filing a patent gets the
>work entered in the only database that USPTO exam
On Mon, May 19, 2014 at 8:09 AM, Mike Hearn wrote:
> The first rule of patents is you do not go looking for patents. US law is
> written in a really stupid way, such that if you knowingly infringe, damages
> triple. Because America uses the patent office as a revenue source,
You have received out
>
> Meh. The world is much bigger than the USA. Secondly that rule makes it
> difficult to educate people about why patents are as bad as they are.
>
You can easily find examples that are not relevant to Bitcoin if you want
to discuss the patent system in general.
> Feel free to continue censori
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 May 2014 20:20:40 CEST, Justus Ranvier wrote:
>You and Gavin could do a lot better by working on a Bitcoin social
>contract - a promise of what features will *never* be added (or taken
>away) from Bitcoin, because despite what you say it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 May 2014 17:09:07 CEST, Mike Hearn wrote:
>The first rule of patents is *you do not go looking for patents*. US
>law is
>written in a really stupid way, such that if you knowingly infringe,
>damages triple. Because America uses the patent o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2014 02:21 PM, Mike Hearn wrote:
>> Submitted with humility and some fear of getting laughed out of
>> here...
>>
>
> Off topic aside, a bunch of us have lately started to think about
> the atmosphere on this list and how to improve it. Nobo
IMO this list is fine for discussing such topics.
Here are some thoughts. I had to deal with patents at Google (my name is on
a few, not my choice unfortunately). Many aspects of patent law are deeply
unintuitive, so here's the crash course as I was given it.
The first rule of patents is *you d
someone recently wrote (not pointing fingers, nor demanding a spirited
defense from that person, its a generic comment):
> PS: the device has patents pending
btw about patents, I wonder if people who feel the need to do that, would
you consider putting those patents into like a linux foundation
On Mon, May 19, 2014 at 3:11 AM, Jeff Garzik wrote:
> On Sun, May 18, 2014 at 1:43 PM, Raúl Martínez wrote:
>> - bitcoind and Bitcoin Core should be in Linux repos:
>
> Agreed with conditions:
> 1) The distro MUST let bitcoin devs dictate which dependent libs are
> shipped with / built statically
Hmm, this is firmcoin thing looks like what I mean. They don't have a
solution yet, and prices they quote smartcards are unacceptable, but if
they will manage to get down in selfcost - that may work. Ok, I'll follow
them and see what it will come to.
Best regards,
Alex Kotenko
2014-05-19 13:55
Alex,
I think the problem of making paper bitcoins is equivalent to the idea of
creating paper implementation of bitcoin sidechain. Hard one in my mind. If
we could resolve this one in secure and decentralized way it would be the
same breakthrough as bitcoin itself is.
Martin Sip
On 18/05/
Asking random ignorant stranger to care to protect themselves never works.
We need solution that requires strictly zero effort.
Best regards,
Alex Kotenko
2014-05-19 14:06 GMT+01:00 Brooks Boyd :
> >> 2014-05-18 13:14 GMT+01:00 Andreas Schildbach :
> >> One problem we couldn't figure out here
>> 2014-05-18 13:14 GMT+01:00 Andreas Schildbach :
>> One problem we couldn't figure out here though - how to protect the
>> notes from unauthorized redeem. Like if someone else tries to reach your
>> wallet with his own NFC - how can we distinguish between deliberate
>> redeem by owner and fraudul
Alex,
I think that what you are talking about more or less something like
the Firmcoin
Check: http://firmcoin.com/?p=92
On 18/05/2014 08:47 a.m., Alex Kotenko wrote:
>
>
> One problem we couldn't figure out here though - how to protect the
> notes from unauthorized redeem. Like if someo
>
> (sure - there are tricks to limit rates anyway, like the script in
> contrib/qos, but to have it generally available the block download
> needs to be more robust first)
One thing we could consider as a short term solution (if headers
first+parallel downloading will take a while, which seems p
On Mon, May 19, 2014 at 11:26 AM, Bjørn Øivind Bjørnsen
wrote:
> On 18/05/14 19:43, Raúl Martínez wrote:
>>
>
> As an interested party not intimately familiar with the bitcoin codebase
> who also spent some time setting up a node a while ago, I would like to
> add one thing to the above list - ne
>
> Does this mean that you can currently actively hurt the network by
> adding a node with a very slow upstream / downstream?
Well, I guess "hurting" the network is perhaps a bit dramatic. There are
already lots of ways the download process can go wrong and take days. Using
the torrent is much f
On 19/05/14 14:15, Mike Hearn wrote:
> As an interested party not intimately familiar with the bitcoin codebase
> who also spent some time setting up a node a while ago, I would like to
> add one thing to the above list - network rate limiting.
>
>
> The problem is that this is easier
> Submitted with humility and some fear of getting laughed out of here...
>
Off topic aside, a bunch of us have lately started to think about the
atmosphere on this list and how to improve it. Nobody should have to fear
getting flamed or laughed at for proposing ideas, even if they turn out to
be
>
> As an interested party not intimately familiar with the bitcoin codebase
> who also spent some time setting up a node a while ago, I would like to
> add one thing to the above list - network rate limiting.
The problem is that this is easier said than done. Bitcoin Core won't
notice a remote p
Is the small number of bitcoin nodes a concern? If yes, why? What kind of
attack can the network suffer? And where can we find statistical information
about the full nodes running?
I guess the only effective incentive to keep a node running would be financial.
A kind of proof of stake would be
On Mon, May 19, 2014 at 10:48 AM, Wladimir wrote:
>
> Some hacking with ncurses could quickly make a decent tool here. It
> could be packaged with bitcoin itself but that's not necessary. For
> example Tor has the tool 'arm' which is a separate package.
Regarding tor-arm, here are some screenshot
Practically I would approach it from a different angle. We need to make
sure that notes we're accepting are still loaded, but assuming it's NFC
enabled this is still quite easy for the user and is an acceptable
usability drawback.
Then what we need to make sure is that when someone is redeeming the
On 18/05/14 19:43, Raúl Martínez wrote:
> About the small number of bitcoin nodes:
> Hi, I read the message that Mike Hearn sent to this mailing list some
> days ago (2014-04-07 11:34:43) related to the number of bitcoin full nodes.
>
> As an owner of two Bitcoin Nodes, one in my home computer and
On Sun, May 18, 2014 at 7:43 PM, Raúl Martínez wrote:
> About the small number of bitcoin nodes:
> Hi, I read the message that Mike Hearn sent to this mailing list some days
> ago (2014-04-07 11:34:43) related to the number of bitcoin full nodes.
>
> As an owner of two Bitcoin Nodes, one in my hom
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2014 09:11 AM, Jeff Garzik wrote:
> Meh. I like example configs, perhaps tuned by the distro. If the
> distro (_not_ Bitcoin Core upstream) chooses to install a
> bitcoin.conf in the proper location, that's up to them.
>
>
>> - bitcoind a
On Sun, May 18, 2014 at 1:43 PM, Raúl Martínez wrote:
> - Allow users to view the bandwith used by Bitcoin Core:
+1 for the sake of transparency
HOWEVER, the impact on this feature RE user population is
unpredictable. Users may see bigger than expected numbers, and switch
off their node.
> -
45 matches
Mail list logo
