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
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
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
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
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
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
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
(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
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
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
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:
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
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
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
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
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
-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
-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
-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
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
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
-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
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
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
-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
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
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
-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
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
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
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
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
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
-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 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
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
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
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:
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
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
40 matches
Mail list logo
