Re: [Bitcoin-development] About the small number of bitcoin nodes

2014-05-19 Thread Jeff Garzik
On Sun, May 18, 2014 at 1:43 PM, Raúl Martínez r...@i-rme.es 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.


 - Educate users about the correct setup of a bitcoin node:

+1

 - bitcoind and Bitcoin Core should create a bitcoin.conf file on the first

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 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 into the bitcoin binaries/libs.
2) The distro MUST permit fresh updates even to older stable distros.
2) The maintainer(s) MUST be active, and follow bitcoin development,
release status, etc. on a near-daily basis, be able to respond quickly
if security issues arise, etc.

Matt C seems to do a good job of this in Ubuntu PPA, I'm told.


 - Create a grafical interface for bitcoind on Linux servers:
 When I say grafical interface I mean like top command, an interface made
 out of characters in ASCII.

The best path for this is figure out what statistics you want to see,
and have bitcoind export those raw numbers to any willing consumer.
Then write your bitcoind-top on top of that.

 - Split Bitcoin Wallet from Bitcoin Node:

+1

In progress.  Disable-wallet support, at compile time or runtime, was
the first step.

 - Inform users if 8333 port is closed:

+1

 - Keep connections if bitcoind is restarted:
 I noticed that if I restart bitcoind (to apply new config) my reset to 0 and
 take some hours to rise up to ~40. I believe that my peers should notice
 that I am down for less than ~15 minutes and try to connect again faster.

No, you don't want this (and it's not possible in many cases anyway).

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
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] Paper Currency

2014-05-19 Thread Alex Kotenko
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 notes
- he has control over physical object itself, ideally for a period of time.

​With some active powered electronics in place it would be easy, but how do
we do it without anything active in place? ​


Best regards,
Alex Kotenko


2014-05-18 21:10 GMT+01:00 Natanael natanae...@gmail.com:

 The problem with not involving any electronics is that somebody needs to
 generate a recoverable private key that we have to trust haven't recovered
 the private key.

 The only plausible solution is multisignature P2SH addresses where you
 trust several independent entities to not collude instead, where you
 combine their paper notes into one piece. And then you still don't know if
 all the private keys are recoverable to you (failed print?).

 - Sent from my phone
 Den 18 maj 2014 20:48 skrev Alex Kotenko alexy...@gmail.com:

 Erm, few things here.
 ​- I can't see really how to embed electronics capable to run an SPV
 cli​ent into printed paper. I know that passive NFC tags can be printed on
 paper, but not actual chips and/or power modules. So we are talking about a
 completely different things here.
 - even with paper notes printed proprietarily by some business the notes
 itself still can have routes for independent blockchain-based verification,
 and you won't need to trust anybody to test it. You will have to trust
 security of the notes itself, but this is same as when you trust the phone
 manufacturer when you're putting your bitcoin wallet on it.

 ​So really I see ​only issues of technical security in here, and this is
 the problem I'm seeking solutions for.


 Best regards,
 Alex Kotenko


 2014-05-18 14:50 GMT+01:00 Natanael natanae...@gmail.com:

 Now you are talking about Trusted Platform Modules. Like smartcards,
 actually. Devices that won't leak their keys but let the holder spend the
 coins. It could even have it's own simple SPV wallet client to make it
 easier to handle. And they'd use the attestation features provided by the
 TPM to prove the software it's unmodified top the current holder.

 But then you still have to trust the manufacturer of the device, and you
 have to trust it has no exploitable side channels.

 - Sent from my phone
 Den 18 maj 2014 13:52 skrev Alex Kotenko alexy...@gmail.com:
 ​


--
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] About the small number of bitcoin nodes

2014-05-19 Thread Wladimir
On Mon, May 19, 2014 at 10:48 AM, Wladimir laa...@gmail.com 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 screenshots:
https://www.atagar.com/arm/screenshots.php

It shows, among other things:
- bandwidth up/down graphs
- CPU usage
- debug logging (in real time)
- connected peers+statistics
- currently active configuration

Would be nice to have a similar tool for bitcoind.

Wladimir

--
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] About the small number of bitcoin nodes

2014-05-19 Thread Felipe Micaroni Lalli
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 nice on bitcoin. But I have no idea how to 
begin with.



Felipe Micaroni Lalli

Walltime: https://walltime.info
Bitcoin Paranoid Android developer
PGP ID: 0x4c0afccfed5cde14
BTC: 1LipeR1AjHL6gwE7WQECW4a2H4tuqm768N

On 19/05/2014, at 07:39, Wladimir laa...@gmail.com wrote:

 On Mon, May 19, 2014 at 10:48 AM, Wladimir laa...@gmail.com 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 screenshots:
 https://www.atagar.com/arm/screenshots.php
 
 It shows, among other things:
 - bandwidth up/down graphs
 - CPU usage
 - debug logging (in real time)
 - connected peers+statistics
 - currently active configuration
 
 Would be nice to have a similar tool for bitcoind.
 
 Wladimir
 
 --
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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] Paper Currency

2014-05-19 Thread Mike Hearn
 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 silly ones. Gavin talked about this in his Bitcoin 2014 keynote and
asked for someone to solve the forum trolling problem.

I don't know if there are any silver bullets per se, but:

1) Please do keep ideas coming. It's easy to mute threads in any good mail
client for people who don't care. If anyone gets too aggressive, the rest
of us will remind them that this is unacceptable.

2) If you're willing to become a list moderator, please get in touch. Gavin
and I are looking for neutral people who are willing to keep up with this
list and help ensure the debate is civilised. Ideally moderation is not
necessary, but that's what we tried so far and we keep getting consistent
feedback from lots of people that it's not working.
--
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] About the small number of bitcoin nodes

2014-05-19 Thread Bjørn Øivind Bjørnsen
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 said than done. Bitcoin Core won't
 notice a remote peer is working but slow and switch to a faster one, and
 even if it did, it'd just mean throttling your connection would cause
 all remote nodes to give up and hit the other unthrottled peers even more.
 

Does this mean that you can currently actively hurt the network by
adding a node with a very slow upstream / downstream? If so, what is the
recommended minimum amount of bandwidth you should allocate for a node?
I've already throttled mine with QoS based on the script in the contrib/
folder.

Bjørn Øivind




signature.asc
Description: OpenPGP digital signature
--
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] About the small number of bitcoin nodes

2014-05-19 Thread Wladimir
On Mon, May 19, 2014 at 11:26 AM, Bjørn Øivind Bjørnsen
bo.bjorn...@gmail.com wrote:
 On 18/05/14 19:43, Raúl Martínez wrote:
 snip some good ideas

 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.

There is already an (old) patch that implements that. It won't be
merged, though, until headers-first and parallel block download is in.
Only when the node can download blocks from multiple peers at once it
is really safe to allow limiting rates.

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

Wladimir

--
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] About the small number of bitcoin nodes

2014-05-19 Thread Mike Hearn

 (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 plausible) is to
add a service bit that says I have chain data and am willing to Bloom
filter it for you, but I won't serve full block data, and then just
exclude all of those from the chain download logic. It should not be a deep
change to the code headers first is impacting, and would allow home users
who may have no tolerance for block chain uploads at all to still take part
and offer useful services to the network.

I know Pieter likes the idea of an archival node service bit, or
something like that. I'd been thinking that the stored chain height value
would be better, but perhaps we need to divorce I have CPU and can filter
from I have bandwidth and can serve more vigorously.
--
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] Paper Currency

2014-05-19 Thread Sergio Lerner
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 someone else tries to reach
 your wallet with his own NFC - how can we distinguish between
 deliberate redeem by owner and fraudulent redeem by anybody else with
 custom built long range NFC antenna? Any ideas?


The firmcoin has two capacitive buttons that you have to press in
sequence to redeem to coins. No long range antenna can do that.

Best regards,
 Sergio.

PS:   the device has patents pending
--
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] Paper Currency

2014-05-19 Thread Brooks Boyd
 2014-05-18 13:14 GMT+01:00 Andreas Schildbach andr...@schildbach.de:
 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 fraudulent redeem by anybody else with custom built
 long range NFC antenna? Any ideas?

 I think you'd need multiple factors to protect against that attack. Like
 encrypting with a key that is printed on the note as an QR code.

On Sun, May 18, 2014 at 7:51 AM, Alex Kotenko alexy...@gmail.com wrote:

 Yes, but it must not sacrifice usability. It's paper money, people are used 
 to it and they have rather high standard of expectations in this area. Any 
 usbility sacrifices in this area result into failure of the whole thing.

 Best regards,
 Alex Kotenko

One thought I had reading through this exchange: I think the general
public is becoming more aware of the hacker with a long range
antenna sort of attack, since credit cards are getting microchips
that can be scanned. There's a few videos I've seen of white hat
hackers demonstrating how a suitcase-sized apparatus carried by
someone walking down the street can scan and make charges on cards in
people's pockets as the attacker brushes past. Hence RFID-blocking
sleeves/wallets are on the market, such that your smart credit card
can't make a purchase while its in your wallet. Is a RFID-blocking
wallet also NFC-blocking? Irregardless of whatever future cash you
choose to carry (be it credit card or bitcoin card/coin/cash), perhaps
its the wallet/purse that needs an upgrade, to ensure your money
doesn't spend itself while its in your pocket, but you can easily
remove it and spend it conveniently?

Brooks

--
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] Paper Currency

2014-05-19 Thread Alex Kotenko
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 bo...@midnightdesign.ws:

  2014-05-18 13:14 GMT+01:00 Andreas Schildbach andr...@schildbach.de:
  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 fraudulent redeem by anybody else with custom built
  long range NFC antenna? Any ideas?
 
  I think you'd need multiple factors to protect against that attack. Like
  encrypting with a key that is printed on the note as an QR code.
 
 On Sun, May 18, 2014 at 7:51 AM, Alex Kotenko alexy...@gmail.com wrote:
 
  Yes, but it must not sacrifice usability. It's paper money, people are
 used to it and they have rather high standard of expectations in this area.
 Any usbility sacrifices in this area result into failure of the whole thing.
 
  Best regards,
  Alex Kotenko

 One thought I had reading through this exchange: I think the general
 public is becoming more aware of the hacker with a long range
 antenna sort of attack, since credit cards are getting microchips
 that can be scanned. There's a few videos I've seen of white hat
 hackers demonstrating how a suitcase-sized apparatus carried by
 someone walking down the street can scan and make charges on cards in
 people's pockets as the attacker brushes past. Hence RFID-blocking
 sleeves/wallets are on the market, such that your smart credit card
 can't make a purchase while its in your wallet. Is a RFID-blocking
 wallet also NFC-blocking? Irregardless of whatever future cash you
 choose to carry (be it credit card or bitcoin card/coin/cash), perhaps
 its the wallet/purse that needs an upgrade, to ensure your money
 doesn't spend itself while its in your pocket, but you can easily
 remove it and spend it conveniently?

 Brooks


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

--
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] Paper Currency

2014-05-19 Thread Martin Sip
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/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 someone else tries to reach your wallet
with his own NFC - how can we distinguish between deliberate redeem by owner
and fraudulent redeem by anybody else with custom built long range NFC
antenna? Any ideas?

 

 

The firmcoin has two capacitive buttons that you have to press in sequence
to redeem to coins. No long range antenna can do that.

Best regards,
 Sergio.

PS:   the device has patents pending 

--
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] Paper Currency

2014-05-19 Thread Alex Kotenko
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 GMT+01:00 Sergio Lerner sergioler...@certimix.com:

  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 someone else tries to reach your
 wallet with his own NFC - how can we distinguish between deliberate redeem
 by owner and fraudulent redeem by anybody else with custom built long
 range NFC antenna? Any ideas?


   The firmcoin has two capacitive buttons that you have to press in
 sequence to redeem to coins. No long range antenna can do that.

 Best regards,
  Sergio.

 PS:   the device has patents pending

--
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] About the small number of bitcoin nodes

2014-05-19 Thread Scott Howard
On Mon, May 19, 2014 at 3:11 AM, Jeff Garzik jgar...@bitpay.com wrote:
 On Sun, May 18, 2014 at 1:43 PM, Raúl Martínez r...@i-rme.es 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 into the bitcoin binaries/libs.
 2) The distro MUST permit fresh updates even to older stable distros.
 2) The maintainer(s) MUST be active, and follow bitcoin development,
 release status, etc. on a near-daily basis, be able to respond quickly
 if security issues arise, etc.

 Matt C seems to do a good job of this in Ubuntu PPA, I'm told.

Update:

(1) and (3) are doable, however, Debian and Ubuntu policies make (2)
very difficult (with the exception of security patches). Micha Bailey
and I worked to get bitcoin removed from Debian and Ubuntu stable
releases because they would not allow (2). There are other mechanisms
that could accomplish (2) (backports, volatile, and updates
repositories), however they are not enabled by default and require
user intervention.

Debian unstable does allow (2) since there is no release, and there is
a package in Debian unstable. That package is blocked from
transitioning to a stable release. We've also blacklisted it from
Ubuntu so that Ubuntu doesn't just autoimport and release the Debian
unstable package in an Ubuntu stable release.

Micha is also working to have all old versions of bitcoin removed from
previous released Ubuntu versions.

Matt C's PPA is the best way of getting (1-3) above on Ubuntu, and the
Debian unstable package is probably the best way of getting (1-3)
above in Debian. Both require users to add a line to their apt sources
list; the Debian package would also require apt pinning.

Regards,
Scott

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


[Bitcoin-development] patents...

2014-05-19 Thread Adam Back
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 defensive
pool?

I imagine a number of other bitcoin companies have patented things, but if
you think ahead a little bit, or look at prior ecash history, patents held
by individuals or companies can be outright dangerous.  

We saw this in the past eg the digicash patents after the company went
bankrupt were sold by the investor to some random large company that parked
it in its huge pile of patents, didnt use it, and prevented anyone else from
using it - stalling Chaum dependent payment innovation for perhaps 5 years
until the thing expired, and a Chaum patent expiry party was held.

Just some food for thought.

hmm Yes and this topic now is more than a bit non dev related.  Sorry about
that.  There seems to be no convenient mailing list format for non-dev stuff
or I would Cc and set Reply-To for example?  (Web forums somewhat suck IMO). 

Adam

--
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] patents...

2014-05-19 Thread Mike Hearn
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 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,
basically everything you can possibly imagine is covered by some ridiculous
patent so if you go looking you will always find applicable patents on
every idea and then you end up potentially much worse off.

Most companies (Google certainly included) have therefore banned their
staff from reading patents, thus ensuring that the whole point of them, the
sharing of knowledge, doesn't actually function! And it's much better I
think if we follow the same policy. So *please do not ever mention that
suchandsuch is patented on this list*! When it comes to patent law,
ignorance is bliss. Patents are written in a heavily obfuscated manner such
that actually trying to learn from them is hard work anyway.


One reason I wrote up the contracts stuff when I did is to get it out there
into the public domain, so people couldn't patent the basics of the Bitcoin
protocol. It'll be much better for everyone if new ideas are just put right
out into the public domain. *Please do not patent Bitcoin related research
you do*, even if you think it's for the best:

1) Defensive patenting doesn't work. The whole idea was mutually assured
destruction, you hit me I'll hit you type of logic, but the prevalence of
shell/troll companies killed off that idea. Plus it turns out that big
companies are quite willing to sue each other into oblivion anyway. Once a
patent exists, it'll be used as a weapon by someone eventually, and
attempting to fight back is probably not a workable strategy. Far better
to ensure the material is simply unpatentable by anyone.

2) Patenting with the intention to sue people using Bitcoin in the same
way: well, if you plan to do this, there's not much to talk about  you
won't make any friends this way.
--
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] Paper Currency

2014-05-19 Thread Justus Ranvier
-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. Nobody should
 have to fear getting flamed or laughed at for proposing ideas, even
 if they turn out to be silly ones. Gavin talked about this in his
 Bitcoin 2014 keynote and asked for someone to solve the forum
 trolling problem.

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.

Maybe start with things like how the Bitcoin protocol will never be
changed to allow for confiscation of funds, regardless of who might
demand such a feature.

You are willing to promise all users of Bitcoin that you'll never
propose to steal their coins, aren't you?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTekt4AAoJEMP3uyY4RQ214QgIAM3DdtAUTG63FG/r9Yg4dWb+
TXWoXRd9AYDg/SAirF6qV+r6K0vohMv8UJhCpX0OnNSOfxKcgVt2CnG8i3iWBRu1
V+LRFmaHkJ+vJLaR2lEdFKMc2DVuZUIXGH6jEgVo/dzFJGZ/GcoUwTBrZztjCHDy
WbpuuIfV2ya1bqkhMOn78pDgkDfXBD7qWQsz0MTzSkPitT0AnUEPxCl3KBWizkdH
shGwE4YNhRSX+yTBaFHVMqFb9LzExEWgIgkgghddKfJzj9REcw6wiotD3DvYaDl7
LPegCttg0vdG4YTVlTH0iMwFYC3qrw/Ab43uqLjTy7aWyFjhsPtKceTE3KpGDrk=
=dRhy
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
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] patents...

2014-05-19 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 19 May 2014 17:09:07 CEST, Mike Hearn m...@plan99.net 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,
basically everything you can possibly imagine is covered by some
ridiculous
patent so if you go looking you will always find applicable patents on
every idea and then you end up potentially much worse off.

Most companies (Google certainly included) have therefore banned their
staff from reading patents, thus ensuring that the whole point of them,
the
sharing of knowledge, doesn't actually function! And it's much better I
think if we follow the same policy. So *please do not ever mention that
suchandsuch is patented on this list*! When it comes to patent law,
ignorance is bliss. Patents are written in a heavily obfuscated manner
such
that actually trying to learn from them is hard work anyway.

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.

Feel free to continue censoring your own discussion within closed corporate 
environments. But to say keeping patent discussion off mailing lists is 
appropriate or wise when the tech news is full of such discussion is silly.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJTekz8MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhX0TB/wNZoi5sWj6n3fM7O7T
emVbrVpuBwOvUEJAFYGmXgb2KXGdheVRhXfcwteQybLG+M+Ra/HAqLq+1YrPmopE
QeldiSc31KAkVLYXQMIfD6QO1PBlvKP7qPLqBEpCc9ocd8XLppTPQ2K8o5soV8VF
z6Jt/Hh74xhkhhb/kEzsQ8YKkg+m26WY9Yggu0Qxtb0OTjL86IhEKpH9ijr08jvV
TKs+PHwou5rt0dT3vqLd8ogb7xihTPx/7tciaXHCOfvxGsEgtqdTsjdHlCJ6cR9a
DrZcrIQnX+s1+YbHs3P4kyBfzNHBwwVuwaf5W5pU6vFp276jhsgT/65J7PqoRmxK
AkXg
=dk4R
-END PGP SIGNATURE-


--
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] Paper Currency

2014-05-19 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 19 May 2014 20:20:40 CEST, Justus Ranvier justusranv...@gmail.com 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.

Maybe start with things like how the Bitcoin protocol will never be
changed to allow for confiscation of funds, regardless of who might
demand such a feature.

Might be worth looking into the recent RFC 7258: Pervasive Monitoring Is an 
Attack for some guidance on how to write such a social contract.

Re: Gavin, note the language in the foundation bylaws:

Section 2.2 The Corporation shall promote and protect both the decentralized, 
distributed and private nature of the Bitcoin distributed-digital currency and 
transaction system as well as individual choice, participation and financial 
privacy when using such systems.

You might want to do a pull-req to add fungibility and rejection of blacklists 
to that list; note Adam Back's comments on how fungibility and privacy are 
inherently linked.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJTek/ZMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhYPIB/9/mhDOei8uMGHmzK41
YdL2ezs4LMPLyCRbo9Eu7MDJAMBaMH4VUbomR0tJVPRS191ifa2F/xGYnbDvk/PG
rLX86uPPMBxZqnVMgZLeKJkUHm3Zlkm1Ti58bMR8VVQuPazBBpkYtsvk+0+8j9su
ke7Xq+OqUGOC03bM4bxtKyBCy1FrCJuFgZEywKhOjr6boANLctDRBZerPqQ4AcjP
tHSAAImcesMhjc/N9LJ4MeygszzblYpdsQeiw8jvvyZI7vCSHuKb+hur+kCszYjD
ygfY9QmoNye2yc0GLZd+kXSMwY6gLIvaAFhv2ElMTMiJ7btHtJJfyEaA9Ub4zEEY
JKeO
=DSjZ
-END PGP SIGNATURE-


--
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] patents...

2014-05-19 Thread Mike Hearn

 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 censoring your own discussion within closed
 corporate environments. But to say keeping patent discussion off mailing
 lists is appropriate or wise when the tech news is full of such discussion
 is silly.


It is both appropriate and wise. Please keep discussion of Bitcoin-relevant
patents elsewhere.
--
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] patents...

2014-05-19 Thread Gregory Maxwell
On Mon, May 19, 2014 at 8:09 AM, Mike Hearn m...@plan99.net 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 outdated advice on this point. In Re Seagate
(http://patentlyo.com/patent/2007/08/in-re-seagate-t.html) this
precident was over-turned (and has subsequently been upheld in other
cases). 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 now:  They're often nearly
inscrutable (especially to people without substantial patent reading
experience), and you may discover potential infringement that creates
more work for you to sort out (especially since people without patent
experience tend to read patents much more broadly than they actually
are).

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 examiners are
_guaranteed_ to consult when doing a prior art search, so it may have
a fighting chance of precluding someone else patenting the same
material later (they may also search the internet and use other
resources, but they're guaranteed to consult the existing patents and
applications). Patents can also be used defensively as leverage in a
licensing negotiation: Without your own patents you don't get invited
to the negotiating table at all with someone else who may hold patents
in a space that you're working on.  These are somewhat thin advantages
so great care is required to make sure that things are setup so that
badness cannot happen later when inevitable changes of ownership
happen.

--
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] patents...

2014-05-19 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 19 May 2014 20:43:15 CEST, Gregory Maxwell gmaxw...@gmail.com 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 examiners are
_guaranteed_ to consult when doing a prior art search, so it may have
a fighting chance of precluding someone else patenting the same
material later (they may also search the internet and use other
resources, but they're guaranteed to consult the existing patents and
applications).

Interesting. Is that to say a viable strategy would be to apply for patents and 
let the application lapse?
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJTelGCMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhQPlCACjJgJEyMYMtF+/dJJh
TgWfVuE7E7QmwgWoQMBo7/5LgO1W5PQt9d3jfQ7gkrdCqTWs4HtA3lcgjdeEQ6ZW
QvMFG5/xITVi85v2zlE9CteQZXLBTSI+J7VlkjqnJeftQkklvGjiDtNfaDDsTacV
ZNem06V4fmBxNgzqmit2Roilp+NMQb2iM9Ofkr5FbI0cT/kzD/IJd2+Crqsu/uDU
8r2YQY0bbEf2wqxVdq5TSf1rFqqnWKHB3lD1GGRJ8n5BciBmysZL43jct8YABSgi
BHFpJP2ii7gz076mRiBb+KwCo+1xKUYNpsJk1m7HND7PjqkXps+JHiNaWdr9vAxx
raFO
=L1oX
-END PGP SIGNATURE-


--
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] patents...

2014-05-19 Thread Mike Hearn

 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 (and there is very likely to be at
least one and possibly many), via whatever means, then by continuing
business you become a wilful violator. Which makes sense: how could it be
any other way?

It still never makes sense to read patents. You can only lose.
--
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


[Bitcoin-development] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Gavin Andresen
On Mon, May 19, 2014 at 2:20 PM, Justus Ranvier justusranv...@gmail.comwrote:


 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.


Now I'm really confused.

Why would Mike or I have the authority to write a social contract to
promise anything about future-Bitcoin?

I thought the only social contract was the decentralized one we have
already-- if you don't like something about the code, then don't download
and run it. Or fork it if you're able.

As the person who started this mailing list, I DO feel like I have the
authority to enforce a social contract of no trolling or flaming or
name-calling here. I'd very much like to delegate that authority, though;
ideally to some software algorithm that automatically censors topics or
people who don't contribute to a productive discussion.

PS: speaking of productive discussion...
... please change the Subject line when the topic wanders.

-- 
--
Gavin Andresen
--
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] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Justus Ranvier
-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 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 Bitcoin, and they can use that information to
make informed decisions about which software they will choose to support.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTemMNAAoJEMP3uyY4RQ21KJMH/1MbnPxZ42sjVjEiGSQBkGfE
E3jt8aAf2DTza8xtybSmT/pHVhx/VUT4UNj9oBZayqJ1eUNr6YMgGCP8J+DxBtN+
mYH4lTnCiR4+hjO9aux0AWFV+hfZSq7A41QH6wymLa5CyywOtc+i7i3qU5ZGrbtX
9yBrQpFilvMIlrAOBDlXUwb06FDK17ZHHX4V5sI8PSRYJvoiWCrk12Vqj1Z95UOy
ayzWGwbO30ky6lGirBXfpu2e2WJADE9sc43ecNCDplUMR4D4n9jwAUldEiMSBKg2
pwUNcfj1gaKkscj4QmGKMbq6yug+lrSa8qq/jFsbQq+2pqT4VjlQlrN52wz7Yeg=
=Jafe
-END PGP SIGNATURE-

--
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] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Mike Hearn
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 correctly identified yourself as one of the people
causing problems on this list. Your vicious attacks are one of the reasons
we're now seeing threads that start with I hope I don't get flamed or
laughed at for this idea but  which is totally unacceptable. I would
prefer you just unsubscribe, in the hope we get a second chance from some
of the potential developers we've lost.
--
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] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Gavin Andresen
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 have much higher tasks on my TODO list.

-- 
--
Gavin Andresen
--
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] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Justus Ranvier
-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 swear an oath not to think bad thoughts, go right ahead and do
 so.
 
 But I'm glad to see you correctly identified yourself as one of the
 people causing problems on this list. Your vicious attacks are one
 of the reasons we're now seeing threads that start with I hope I
 don't get flamed or laughed at for this idea but  which is
 totally unacceptable. I would prefer you just unsubscribe, in the
 hope we get a second chance from some of the potential developers
 we've lost.
 

I'm glad to see you correctly identified yourself as well.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTemXNAAoJEMP3uyY4RQ21KNUH/12vTPOPNjQQIunTkNCSqV6P
hub7mrW/hS4NSlK7P3Laq5qj+qB9ou/uIRCPP6uIhk6scicbukn31nw1p/er0YoQ
XGFE+SmF+Z5Ysz/5uA1OP9VdjBKggbI6rFVZKbt5DwrFK0gCDMtgcxO2y6CFGR+U
mFhD9ORf/NdAozFanXSEk81p5OfZqhhnxaPPpPnwQeojtLwE20reLrEcCKy6XMEs
Mtfan+qgPJYTmWiWmDHsrFsz+5HwpkR5giDf4hzW5J1F8Vj+LTPXjGz9Txldk89t
0dRmYFAtE74QgXsIRvWny9ho4YL/Nn+WHf0Qf3HKh31wrzSea0KFKpPaa32xpKA=
=jIov
-END PGP SIGNATURE-

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

2014-05-19 Thread Alex Kotenko
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 addresses for it. That's 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 andr...@schildbach.de:

 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, that's my understanding too.

  If I'll start a DNS seed of my own and make sure it works well, will
  this help?

 Yes, definately.

  I've found this DNS seeder daemon
  https://github.com/sipa/bitcoin-seeder, 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, I'll setup a DNS seeds for mainnet
  and for testnet at bitcoin-seed.alexykot.me
  http://bitcoin-seed.alexykot.me and testnet-seed.alexykot.me
  http://testnet-seed.alexykot.me, 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 you've 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
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

2014-05-19 Thread Alex Kotenko
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 m...@osfda.org wrote:

 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
 custom proxy application.

 -
 Michael Wozniak


 On May 19, 2014, at 4:14 PM, Alex Kotenko alexy...@gmail.com wrote:

  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 addresses for it. That's 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 andr...@schildbach.de:
  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, that's my understanding too.
 
   If I'll start a DNS seed of my own and make sure it works well, will
   this help?
 
  Yes, definately.
 
   I've found this DNS seeder daemon
   https://github.com/sipa/bitcoin-seeder, 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, I'll setup a DNS seeds for mainnet
   and for testnet at bitcoin-seed.alexykot.me
   http://bitcoin-seed.alexykot.me and testnet-seed.alexykot.me
   http://testnet-seed.alexykot.me, 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 you've 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
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 
 --
  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


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

2014-05-19 Thread Michael Wozniak
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 custom proxy 
application.

-
Michael Wozniak


On May 19, 2014, at 4:14 PM, Alex Kotenko alexy...@gmail.com wrote:

 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 addresses for it. That's 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 andr...@schildbach.de:
 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, that's my understanding too.
 
  If I'll start a DNS seed of my own and make sure it works well, will
  this help?
 
 Yes, definately.
 
  I've found this DNS seeder daemon
  https://github.com/sipa/bitcoin-seeder, 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, I'll setup a DNS seeds for mainnet
  and for testnet at bitcoin-seed.alexykot.me
  http://bitcoin-seed.alexykot.me and testnet-seed.alexykot.me
  http://testnet-seed.alexykot.me, 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 you've 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
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 --
 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


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

2014-05-19 Thread Robert McKay
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] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Gregory Maxwell
On Mon, May 19, 2014 at 1:01 PM, Justus Ranvier justusranv...@gmail.com 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 Bitcoin, and they can use that information to
 make informed decisions about which software they will choose to support.

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, diverting
them from real development and review work, all as commanded. Maybe
I'll try to sneak out a warning of some kind, maybe... but with my
life or my families or friends lives on the line— probably not.

... and I think that anyone who tells you otherwise probably just
hasn't really thought it through.  So what is the point of commitments
like that?  People change, people go crazy, people are coerced. Crap
happens, justifications are made, life goes on— or so we hope.

What matters is building infrastructure— both social and technical—
that is robust against those sorts of failures. If you're depending on
individual developers (including anonymous parties and volunteers) to
be somehow made more trustworthy by some promises on a mailing list
you've already lost.

If you care about this you could instead tell us about how much time
you promise to spend reviewing technical work to make sure such
attacks cannot be successful, regardless of their origins. Where are
your gitian signatures? I think thats a lot more meaningful, and it
also improves security for everyone involved since knowing that such
attacks can not succeeded removes the motivation for ever trying.

A lot of what Bitcoin is about, for me at least, is building systems
which are as trustless as possible— ruled by unbreakable rules
embodied in the software people chose to use out of their own free
will and understanding. Or at least thats the ideal we should try to
approximate. If we're successful the adhomenim you've thrown on this
list will be completely pointless— not because people are trusted to
not do evil but because Bitcoin users won't accept technology that
makes it possible.

So please go ahead and assume I'm constantly being evil and trying to
sneak something in... the technology and security can only be better
for it, but please leave the overt attacks at the door. Think
gentleman spies, not a street fighting death match. The rude attacks
and characterizations just turn people off and don't uncover actual
attacks.  Maybe the informal guideline should be one flame-out
personal attack per cryptosystem you break, serious bug you uncover,
or impossible problem you solve. :)

--
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] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Justus Ranvier
-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,
 diverting them from real development and review work, all as
 commanded. Maybe I'll try to sneak out a warning of some kind,
 maybe... but with my life or my families or friends lives on the
 line— probably not.
 
 ... and I think that anyone who tells you otherwise probably just 
 hasn't really thought it through.  So what is the point of
 commitments like that?  People change, people go crazy, people are
 coerced. Crap happens, justifications are made, life goes on— or so
 we hope.

I presume you're familiar with the concept of a warrant canary, so
presumably you'd also see why public statements such as I was
discussing would be similarly useful.

Social contracts make it more difficult to hide coercion, which serves
no one except the attackers.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTenU+AAoJEMP3uyY4RQ21P1UH/2fvYa7Hfv53eXA0k9appRVI
8KWpH2D95zCo/s6kIeKZtmEzhFWFkKxOHwiHZbD5JokG+U/vUeR8p+SxF1/xUc1X
1tTNAjfAALz0/KzjPKmlMQCqM5vT4yumHsDusqPuzbPFnJnwFufrAW9vWu9OJacs
JEv4yoRGNZhR+eM8hCUkDfTtj7D8J3gMYyYds7K4kppiHN2UPRgZT6TCVyCRlThe
8w9MzYoTAf1WXPmzvSfPhzKMfNV9Y+tjt6ZV+KyLG1ZGLw2EDCxJR1O23QQE8IfK
53I2RgeFnvcdceoExSfYJj+kNpbPQ/WDVszswO5esoMWJ/E3j5PCBsLdGt+8e7I=
=BysA
-END PGP SIGNATURE-

--
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] patents...

2014-05-19 Thread Bernd Jendrissek
On Mon, May 19, 2014 at 5:09 PM, Mike Hearn m...@plan99.net 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. Google can survive single or triple damages, so it makes sense to
hope that of those patents you necessarily violate due to the size of
your operations, they attract only single damages. Google has so many
fingers in so many pies that violating some patents is a question of
when, not if. Bitcoin has a far narrower scope than trying to take
over the world (and moon).

Happy reading: http://endsoftpatents.org/2010/03/transcript-tridgell-patents/

TL;DR: If even single damages result in commercial death, you better
pay attention to patents, to reduce the chances of accidentally
running into one.

(But Bitcoin is not ccache either - it's all about money and it isn't
inconceivable that a patent infringement suit might not result in
commercial death. The right answer here isn't as obvious as you make
it out to be.)

--
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] Developer documentation on bitcoin.org

2014-05-19 Thread Saïvann Carignan
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 very appreciated.

Saïvann


Le 2014-05-10 22:08, Saïvann Carignan a écrit :
 A new Developer Documentation section should be soon merged on
 bitcoin.org .
 
 Live Preview:
 http://bitcoindev.us.to/en/developer-documentation
 
 GitHub Pull Request:
 https://github.com/bitcoin/bitcoin.org/pull/393
 
 Bitcointalk Thread:
 https://bitcointalk.org/index.php?topic=511876.0
 
 We've worked hard to come up with good quality documentation and general
 feedback has been positive. Reviews from experienced Bitcoin developers
 would now be much appreciated. You are cordially invited to help
 proofread the documentation so it can be published soon!
 
 *Please avoid commenting on the mailing list* to not spam everyone. See
 the pull request for instructions. Comments should go on the pull
 request or bitcoin-documentation mailing list
 https://groups.google.com/forum/#!forum/bitcoin-documentation .
 

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

2014-05-19 Thread Jeff Garzik
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

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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

2014-05-19 Thread Michael Wozniak
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_bind


On May 19, 2014, at 7:49 PM, Jeff Garzik jgar...@bitpay.com 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
 
 -- 
 Jeff Garzik
 Bitcoin core developer and open source evangelist
 BitPay, Inc.  https://bitpay.com/
 
 --
 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


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

2014-05-19 Thread Robert McKay
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

2014-05-19 Thread Robert McKay
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