Bitcoin Core version 0.9.1 is now available from:
https://bitcoin.org/bin/0.9.1/
This is a security update. It is recommended to upgrade to this release
as soon as possible.
It is especially important to upgrade if you currently have version
0.9.0 installed and are using the graphical interfac
Those clarifications are what I needed to hear. For some reason I started
thinking about this last night and wanted to bring it up just in case it
would help, but def. not necessary. Will get back to more low hanging fruit
in the UI/UX as I get to know the project more.
Gregory: "But there doesn't
My node (based in Dallas, TX) has about 240 connections and is using a
little under 4 Mbps in bandwidth right now.
According the hosting provider I'm at 11.85 Mbps for this week, using 95th
percentile billing. The report from my provider includes my other servers
though.
On Mon, Apr 7, 2014 at 1
On Tue, Apr 8, 2014 at 6:13 PM, Angel Leon wrote:
> I was wondering if the level of traffic a Bitcoin node gets is or will be
> so high that you have heard/will hear complains like the following:
>
>
>1. a home router that crashes or slows down when its NAT pin-hole
>table overflows, trig
On Tue, Apr 8, 2014 at 9:13 AM, Angel Leon wrote:
> a home router that crashes or slows down when its NAT pin-hole table
> overflows, triggered by many TCP connections.
We don't form or need to form a great many connections.
> a home router that crashes or slows down by UDP traffic
We don't use
only that in the real world most routers suck and people don't even know
how to configure them (reminds me of the convo about people not installing
plugins)
this is why the wheel had to be reinvented for the bittorrent world, and it
works.
http://twitter.com/gubatron
On Tue, Apr 8, 2014 at 12:30
On Tuesday, 8 April 2014, at 12:13 pm, Angel Leon wrote:
> I was wondering if we have or expect to have these issues in the future,
> perhaps uTP could help greatly the performance of the entire network at
> some point.
Or people could simply learn to configure their routers correctly. The only
t
On Tue, Apr 8, 2014 at 5:58 PM, Andreas Schildbach wrote:
> On 04/08/2014 05:46 PM, slush wrote:
>
> > It still doesn't mean that bitcoinj or Electrum cannot share the bare
> > minimum of BIP XX. Of course if somebody will use Electrum for 2to3
> > transactions and then move wallet to client which
I was wondering if the level of traffic a Bitcoin node gets is or will be
so high that you have heard/will hear complains like the following:
1. a home router that crashes or slows down when its NAT pin-hole table
overflows, triggered by many TCP connections.
2. a home router that crashe
On 04/08/2014 05:46 PM, slush wrote:
> I understand each client will implement things a little bit different,
> for example the current plan is bitcoinj will hold all keys in memory
> and start reusing keys on low resources. Electrum uses a chain for their
> private purpose. Etc.
>
On Tue, Apr 8, 2014 at 4:49 PM, Andreas Schildbach wrote:
> While there is an agreement that a standard would be useful for sharing
> wallets, we certainly didn't agree on every aspect of a standard. At
> least not on this thread, and also not at the Berlin meeting.
>
>
We're going to write down B
On Tue, Apr 8, 2014 at 3:53 PM, Pieter Wuille wrote:
> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would have expected that different cha
On Tue, Apr 8, 2014 at 4:13 AM, Mike Hearn wrote:
> I'd be careful with swift generalisations. It depends a lot on the value of
> your product. I didn't have any hangups about installing a plugin to use my
-You- are irrelevant, as am I. We don't mind such things.
But based on personal observati
On 04/08/2014 02:43 PM, slush wrote:
> After some off-list discussion about details with wallet developers, it
> seems that structure
>
> m/'/'//
>
> fulfill requirements of all wallet developers around, including
> myTrezor, Electrum, Multibit, Wallet32 and other software is willing to
> adapt
On 04/08/2014 03:53 PM, Pieter Wuille wrote:
> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string
+1
I would prefer that solution...
Le 08/04/2014 15:53, Pieter Wuille a écrit :
> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would h
Pieter,
your suggestion has charm since “Bitcoin seed” would even not need
a global dictionary like the interpretation of the first level, since it would
be self describing.
Regards,
Tamas Blummer
http://bitsofproof.com
On 08.04.2014, at 15:53, Pieter Wuille wrote:
> I see the cause of our
I see the cause of our disagreement now.
You actually want to share a single BIP32 tree across different
currency types, but do it in a way that guarantees that they never use
the same keys.
I would have expected that different chains would use independent
chains, and have serializations encode w
tl;dr;
It is dangerous to expect that other seed than "xprv" does not contain
bitcoins or that "xprv" contains only bitcoins, because technically are
both situations possible. It is still safer to do the lookup; the magic
itself is ambiguous.
Marek
On Tue, Apr 8, 2014 at 3:40 PM, slush wrote:
On Tue, Apr 8, 2014 at 3:18 PM, Pieter Wuille wrote:
> I still don't understand the purpose of cointype. If you don't want to
> risk reusing the same keys across different currencies, just don't use
> the same seed or the same account? That is purely a client-side issue.
>
>
Of course it is purely
I still don't understand the purpose of cointype. If you don't want to
risk reusing the same keys across different currencies, just don't use
the same seed or the same account? That is purely a client-side issue.
If the consensus is to add the cointype anyway, can we fix it to be
equal to the 4-by
After some off-list discussion about details with wallet developers, it
seems that structure
m/'/'//
fulfill requirements of all wallet developers around, including myTrezor,
Electrum, Multibit, Wallet32 and other software is willing to adapt once
anything will be standardized (i.e. they don't ca
On Monday, 7 April 2014, at 7:07 pm, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 6:46 PM, Matt Whitlock wrote:
> > On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote:
> >> On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
> >> wrote:
> >> > Regarding the choice of fields, any implementat
On 07/04/14 15:50, Gregory Maxwell wrote:
> Bitcoin.org recommends people away from running Bitcoin-QT now, so I'm
> not sure that we should generally find that trend surprising.
What options are out there for people caring about 20GB blockchain?
Depending of third party server is not an option.
I'd be careful with swift generalisations. It depends a lot on the value of
your product. I didn't have any hangups about installing a plugin to use my
TREZOR: compared to the cost and effort involved with the rest of it,
installing a plugin was by far the easiest part.
Another example. Back in 2
Specialization of nodes is ongoing most prominent with SPV wallets and mining.
There is a need I see on my own business for software that is able to serve
multiple wallets, and is multi tiered,
so the world facing P2P node can be in a DMZ. I target them with a hybrid model
that is SPV plus mempo
>
> Multi-sig requires infrastructure. It isn't a magic wand that we can
> wave to make everyone secure. The protocols and techniques necessary
> don't exist yet, and apparently no one has much of an incentive to
> create them.
It is starting to happen. If you're OK with using a specific web wa
Isn't that just conceding that p2p protocol A is better than p2p protocol B?
Can't Bitcoin Core's block fetching be improved to get similar performance as a
torrent + import?
Currently it's hard to go wide on data fetching because headers first is still
pretty 'beefy'. The headers can be compre
28 matches
Mail list logo
