> It sounds to me that you're insisting that you're asking people who
> oppose degrading our recommendations to commit to a costly rushed
> development timeline. I think this is a false choice.
Hardly. I don't have any particular timeline in mind. But I disagree
we have "forever". New ideas have a
>> I was under the impression that "connectedness" was the real metric of
>> concern
I think the real thing we need full nodes for is "sockets" where by
socket I mean "resources needed to serve another node".
Last year we actually ran out of sockets and it took forever for new
nodes to connect be
Escrow/multisig is complicated enough to wait for another day. But
certainly having a payment protocol is an important step towards it
On 6 Dec 2012 07:32, "Andreas Petersson" wrote:
> During/before the Payment Request there should be a method to exchange
> the public keys to be able to generate
Re: the newest spec. Rather than make the signature over the
"concatenation of", why not just make it a signature over the
serialized protobuf minus the signature field (as I did in my demo
code). Otherwise it seems like we'd need more code than really
necessary. We can state explicitly tags must b
> OK. I want to keep the signature field required, though, so how about:
>
> signature: digital signature over a protocol buffer serialized variation of
> the SignedPaymentRequest message where signature is a zero-byte array and
> fields are serialized in numerical order (all current protocol buffe
ashing their clients doesn't achieve anything as long as the crash
isn't exploitable.
On Fri, Dec 7, 2012 at 11:45 AM, Mike Hearn wrote:
>> OK. I want to keep the signature field required, though, so how about:
>>
>> signature: digital signature over a protocol buffer
> yeah... I had similar thoughts on what to do if some Outputs specify an
> amount and others don't. I'm still waffling on whether or not I like
> allowing repeated Outputs; a single Output would make the spec a fair bit
> simpler
Yes, but at the cost of privacy. Generators of payment requests alw
Can we please drop the binary vs text issue? We have been around it
millions of times already. There are no compelling arguments to use
text here and several obvious problems with it. If you think you've
found a good argument to use JSON, please research protocol buffers
more thoroughly and see if
Thanks for the thoughts. For those who don't know, Stephen works for BitPay.
> My first observation is that the proposal is too heavily oriented around a
> merchant/customer interaction.
The term "merchant" is just being used to mean the entity requesting
the payment. I'm hopeful that in future m
I pushed a fix for this.
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value
macx-g++", which perhaps ends up making
gcc stricter than it's supposed to be.
On Thu, Nov 29, 2012 at 8:34 PM, Mike Hearn wrote:
> I found that the problem is the version of the Qt SDK I used didn't
> like the new MacOS version. Re-installing Qt fixed it.
>
> On Mo
Here's a quick update on where we're up to.
Thanks to Matts excellent work, I was able to test his bitcoinj and
bitcoin-qt work together today. There are a few minor tweaks needed,
but I feel like we're maybe a week away from having all the code in a
mergeable state. Here is the remaining work:
-
I did some very rough initial performance tests.
Syncing from a local peer gives me about 50 blocks per second in the
later parts of the chain (post SD), which is about a 10-20x speedup
over what I could do before. This is on a MacBook Pro. But at those
points it's clearly bottlenecked by bitcoind
Oh, one last stat - syncing the entire chain with a wallet containing
two keys and a 0.0001 FP rate (one or two FPs every 5 blocks or so)
resulted in a download of about 46mb of data.
On Fri, Jan 11, 2013 at 3:11 PM, Mike Hearn wrote:
> I did some very rough initial performance te
Matts latest code has been tested by Andreas and seems to work
correctly. He had to extend the client a bit to refresh the filter
every 25k blocks because even with the extra flag, eventually the
filter degrades into uselessness, but it did still improve the
situation quite a bit.
Because it's uni
rallo wrote:
> Actually, there is one more minor algorithmic change I would like to
> make to the way the hash function is computed really quick before it
> gets merged, I'll have that finished up by the end of today.
>
> Matt
>
> On Wed, 2013-01-16 at 11:43 +0100, Mike
is one more minor algorithmic change I would like to
> make to the way the hash function is computed really quick before it
> gets merged, I'll have that finished up by the end of today.
>
> Matt
>
> On Wed, 2013-01-16 at 11:43 +0100, Mike Hearn wrote:
> > Matts latest
comes out, as otherwise there's a
risk that 0.7 snapshot nodes will get overloaded.
On Wed, Jan 30, 2013 at 12:09 PM, Mike Hearn wrote:
> Andreas has uploaded Android builds that use the new bloom filtering and
> peer selection code (also, dependency analysis of transactions).
>
>
Can somebody please unlock the BIP wiki page? I don't know why it was
locked but it's stale.
On Wed, Jan 30, 2013 at 12:13 PM, Mike Hearn wrote:
> Sorry, to clarify, these are test builds available here:
>
>
> https://code.google.com/p/bitcoin-wallet/downloads/deta
> So what exactly was the OP_RETURN bug anyway? I know it has something to
> do with not executing the scriptSig and scriptPubKey separately
> (https://bitcointalk.org/index.php?topic=58579.msg691432#msg691432) but
> commit 7f7f07 that you reference isn't in the tree, nor is 0.3.5 tagged.
>
It was
I'm pleased to announce the release of version 0.7 of the bitcoinj Java
library for working with Bitcoin. Bitcoinj forms the foundation of
MultiBit, Bitcoin Wallet for Android, SatoshiDice and more.
To get bitcoinj 0.7, check out our source from git and then run *git reset
--hard a9bd8631b904*. Th
013 at 8:33 AM, Mike Hearn wrote:
> > Can somebody please unlock the BIP wiki page? I don't know why it was
> locked
> > but it's stale.
>
> I asked for permissions to unlock it but haven't heard back— will prod.
>
-
To summarize your post - it's another go at arguing for strongly
limited block sizes, this time on the grounds that large blocks make
it easier for $AUTHORITY to censor transactions? Is that right?
--
Symantec Endpoint Pro
As an aside, there's a paper coming out in perhaps a few months that
describes a new way to provide Chaum-style privacy integrated with
Bitcoin, but without the use of blinding and without any need for
banks. It's quite smart, I was reviewing the paper this week.
Unfortunately the technique is too
Why does demurrage even still come up? The base rules of Bitcoin will
not be changing in such a fundamental way.
With regards to trying to minimize the size of the UTXO set, this
again feels like a solution in search of a problem. Even with SD
abusing micropayments as messages, it's only a few hun
> This would be bloating UTXO data at a speed of 52 GB/year. That's a very
> big memory leak. And this is just the unspendable outputs.
Firstly, the UTXO set is a LevelDB, it's not stored in memory. Outputs
that never get spent are not in the working set by definition, after a
while they just end
> Isn't there danger of an attack if UTXO is not stored in fast storage?
RAM is used as a database cache.
But regardless, what kind of attack are you thinking of? Using up all
available disk seeks by sending a node a lot of fake transactions that
connect to unspent outputs, but have invalid trans
Just so we're all on the same page, can someone confirm my
understanding - are any of the following statements untrue?
BDB ran out of locks.
However, only on some 0.7 nodes. Others, perhaps nodes using different
flags, managed it.
We have processed 1mb sized blocks on the testnet.
Therefore it is
However, most nodes are not running in such a loop today. Probably
almost no nodes are.
I suppose you could consider mass node death to be more benign than a
hard fork, but both are pretty damn serious and warrant immediate
action. Otherwise we're going to see the number of nodes drop sharply
over
> We just saw a hard-fork happen because we ran into previously unknown
> scaling issues with the current codebase.
Technically, it with the previous codebase ;)
--
Symantec Endpoint Protection 12 positioned as A LEADER i
I'm not even sure I'd say the upgrade "went wrong". The problem if
anything is the upgrade didn't happen fast enough. If we had run out
of block space a few months from now, or if miners/merchants/exchanges
had upgraded faster, it'd have made more sense to just roll forward
and tolerate the loss of
My general hope/vague plan for bitcoinj based wallets is to get them all on
to automatic updates with threshold signatures. Combined with regular
audits of the initial downloads for new users, that should give a pretty
safe result that is immune to a developer going rogue.
On Wed, Apr 3, 2013 at
By the way, I have a download of the Bitcoin-Qt client and signature
verification running in a cron job.
On Thu, Apr 4, 2013 at 10:11 AM, Mike Hearn wrote:
> My general hope/vague plan for bitcoinj based wallets is to get them all
> on to automatic updates with threshold signatures. Co
51% isn't a magic number - it's possible to do double spends against
confirmed transactions before that. If Michael wanted to do so, with the
current setup he could, and that's obviously rather different to how
Satoshi envisioned mining working.
However, you're somewhat right in the sense that it'
In bitcoinj we desperately need integration tests to exercise the wallet
code, and I think if it was done well the tests would be applicable to
bitcoind as well. There have been a series of bugs in bitcoinj that boiled
down to "the unit tests were not realistic enough", either because they
stopped
It'd help to know how the signatures are invalid.
On Sun, Apr 7, 2013 at 5:34 PM, Pieter Wuille wrote:
> (cross-post from bitcointalk.org)
>
> Hello all,
>
> as some may know, Bitcoin uses DER-encoded signatures in its transactions.
> However, OpenSSL (which is used to verify them) accepts more
OK, as the start of that conversation is now on the list, I might as well
post the other thoughts we had. Or at least that I had :)
It's tempting to see this kind of abuse through the lens of fees, because
we only have a few hammers and so everything looks like a kind of nail. The
problem is the m
> Makes bringing up a new node dependent on other nodes having consistent
> uptimes, particularly if you are on a low-bandwidth connection.
>
This is already the case and always has been.
> NAK
>
> No blacklists
If you're volunteering to store and serve the chain no matter what it
contains, in
> However, there should be some metrics and heuristics that take care of
> this problem. Notably the dev consensus (sans you, Mike :)) seems to
> be that uneconomical outputs should be made non-standard.
I think that patch is ok as it doesn't really have any fixed concept of
what is uneconomical
AV software changes all the time, I definitely recall cases where AV got
interested in, eg, web browser caches and ended up corrupting things. But
that might be because it knew the files were written by a web browser.
Lightly frying the contents has the disadvantage of no mmap and no
sendfile() in
I'm happy to announce the release of bitcoinj 0.8, a Java library for
writing Bitcoin applications. Both simplified and full verification are
supported. BitcoinJ has been used to create everything from end-user wallet
apps to network crawlers to SatoshiDice.
To get bitcoinj 0.8, check out our sour
:
> On Tuesday 09 April 2013 22:03:35 Mike Hearn wrote:
>
> > To get bitcoinj 0.8, check out our source from git and then run *git
> fetch
> > --all; git checkout **cbbb1a2bf4d1*. This will place you on the 0.8
> release
> > in a secure manner. This message was written
This was previously discussed on the forums a bunch of times, but in
particular here:
https://bitcointalk.org/index.php?topic=91732.0
BTW, I don't think all this has to be solved to re-activate replacement on
testnet. It's useful for people to be able to develop apps that use this
feature, inde
> Or are you talking about some sort of new decentralized high frequency
> trading system that is self-matching and self-clearing? (I'd be very
> interested in hearing more if this is the case).
>
I'm using the term "high frequency trading" because Satoshi did. Like the
way he used the word "contr
When this system was first being discussed, Gavin was concerned that miner
incentives were to ignore replacements because it meant extra work and the
replacement might have equal or lower fees than before (or indeed, no
fees). He proposed two solutions: one is to progressively raise the fee on
each
When did I say DoS was unimportant? I just wrote a giant email explaining
how it can be resolved.
I think it's worth pointing out that Bitcoin was launched with no DoS
protection at all, and it's still here. There are still obvious DoS bugs
being fixed with every release. So yes, it's important to
> An attack still shuts down useful tx replacement though. For instance in
> the adjusting payments example an attacker sets up a legit adjusting
> payment channel, does a bunch of adjustments, and then launches their
> attack. They broadcast enough adjustments that their adjustment session
> looks
On Thu, Apr 18, 2013 at 11:28 AM, Mike Hearn wrote:
> With the sipaspeed patches it seems ECDSA can be processed on modern cores
> at something like 20,000 signatures per second. So it'd take a bit over 4
> seconds to process all of them (cpu time).
>
Sorry brainfart, s/cores/c
> ...and actually, that's not a problem if the defender is online, because
> they can just broadcast the highest sequence numbered tx, which blocks
> further broadcasts by the attacker.
Good point - transactions can be ordered by highest version seen before
they're signature checked. Even without
Indeed, as I mentioned in my first mail, nodes can be told how much
bandwidth they're allowed to use and then prioritize within that, so I
don't see any way convergence can fail. And regardless, I used 10mbit for
the calculations, that isn't exactly unlimited. My home internet connection
is better
Yes, this is an excellent observation. Thanks Jeremy and Peter. It's much
less general than full blown tx replacement+lock times, but for the case of
a channel between two people that only ever increases in one direction, it
can work. Thanks. I will try implementing this myself for testing on the
m
HTML5 allows web apps to register themselves for handling URI schemes, such
as the bitcoin: URI that is already in use and being extended as part of
the payment protocol.
The bad news is that for security reasons there is a whitelist of
acceptable schemes in the spec:
http://www.whatwg.org/specs/
(for background: I did a lot of the design work with Gavin on the payment
protocol and suggested/prototyped using x.509 in the way we do).
So, I'm not a fan of weird hacks involving non-existent domain names.
There's a clean way to implement this and we decided to punt on it for v1
in order to get
> Chaining a custom cert onto the end doesn't work, at least not if your
> "end" is the SSL cert. Chaining it to the SSL cert defeats the OP's
> intention of "cold signing", as the SSL private key is usually kept
> online, therefore can't be used to sign a pubkey that is supposed to
> stay offline.
>
> > That's a pointless goal to try and solve right now, because the SSL
> > PKI cannot handle compromised web servers and so neither can we (with
> > v1 of the payments spec).
>
> I don't think the OP intended to solve it "right now", i.e. in v1.
>
> He differentiated between "most trusted" and "
>
> So I don't see how you can have a payment request signing key that's safer
> than an SSL key. As Jeremy notes, CAs will not issue you intermediate
> certificates. Perhaps if one existed that would do the necessary things for
> a reasonable price you could indeed give yourself an offline interme
On Thu, Apr 25, 2013 at 4:13 PM, Mike Caldwell wrote:
> I am not sure if my replies hit the list. If not, can anyone who sees this
> help?
>
> In the past, I have pre signed (with PGP) large batches of Bitcoin
> addresses for distribution on my server. This way, even in the event of
> compromise,
I'd imagined that nodes would be able to pick their own ranges to keep
rather than have fixed chosen intervals. "Everything or two weeks" is
rather restrictive - presumably node operators are constrained by physical
disk space, which means the quantity of blocks they would want to keep can
vary wit
That's true. It can be perhaps be represented as "I keep the last N blocks"
and then most likely for any given node the policy doesn't change all that
fast, so if you know the best chain height you can calculate which nodes
have what.
> Disconnecting in case something is requested that isn't serv
> Backing up a step, I'm not sure what the threat model is for signing the
> refund address? The same process that's signing the transaction is doing an
> HTTPS POST with the refund address.
>
It's a real threat, albeit an exotic one. The threat model is a malware
compromised host, with a wallet
Chrome has whitelisted bitcoin: URIs for web apps, and Firefox it turns out
doesn't use whitelisting at all, so it already works there.
https://chromiumcodereview.appspot.com/14531004
I'm hoping this means web wallet developers won't be put off from
supporting the payment protocol (that risk is t
> Yes, I like that better than broadcasting the exact height starting at
> which you serve (though I would put that information immediately in the
> version announcement). I don't think we can rely on the addr broadcasting
> mechanism for fast information exchange anyway. One more problem with this
> If you're going to take a step like that, the
> should be rounded off, perhaps to some number of bits, or you'll allow
> DNS caching to be defeated.
>
Don't the seeds already set small times? I'm not sure we want these
responses to be cacheable, otherwise there's a risk of a wall of traffic
sud
You are welcome to optimise P2P addr broadcasts or develop better bootstrap
mechanisms.
On Sun, May 5, 2013 at 3:12 PM, John Dillon
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sorry I should have used the word bootstrapping there rather than
> discovery.
> But again I think th
It's expected to be there, yes.
On Mon, May 6, 2013 at 9:56 AM, Addy Yeow wrote:
> >From https://en.bitcoin.it/wiki/Protocol_specification#version, is the
> relay field (bool/1 byte) required in all version packets coming from
> client with protocol version >= 70001?
>
>
> -
Subject change to reflect that this is off-topic for the old thread.
Eventually, I think it makes sense to move to a system where you get seeds
> from
> a DNS (or other mechanism), connect to one or a few of the results, do a
> getaddr,
> fill your peer IP database with it, and disconnect from the
> > I've noticed on my Android phone how it often takes quite awhile to find
> > a peer that will actually accept an incoming connection, which isn't
> > surprising really: why should a regular node care about responding to
> > SPV nodes quickly?
I haven't seen that - remote nodes don't have any s
> Speaking of, off-topic for this discussion, but in the future
> node-to-node communicate should be encrypted and signed
Yes, I'd like to do this. The threat isn't really ISPs which are
mostly trustable (the worst they normally do outside of places like
China is dick about with ads), the big thre
> You mean scam you with a zero-conf transaction that hasn't actually been
> broadcast?
Yeah. Or just scam you at all. It's hard to imagine an organisation as
a big as a mobile carrier engaging in financial scamming (roaming fees
excepted).
I've said this before, but I think it's worth repeating.
> Seems like the website redesign managed to hide the signatures pretty
> good. They're in the release announcements in any case, but that
> should be fixed. Even when they were prominently placed, practically
> no one checked them. As a result they are mostly security theater
Security theater in
> And even without a PGP WoT connection, if the website had SSL enabled, they
> can trust the binaries its sending to the extent that it is securely
> maintained
Yes, it would be nice to have SSL but that requires finding
alternative file hosting.
> I guess its the least of the concerns but I bel
2038 issues only apply to use of signed timestamps, I thought we treat
this field as unsigned? Is it really a big deal?
On Thu, May 9, 2013 at 1:12 PM, Pieter Wuille wrote:
> On Wed, May 08, 2013 at 10:42:44PM -0400, Peter Todd wrote:
>> Ah, shoot, I just realized we both got missed Pieter's poin
> I've been thinking about a decentralized way to create an anonymous
> identity
This is the fidelity bond/anonymous passport idea that has been kicked
around in the forums quite a few times. I mentioned it on the tor-talk once
as a solution to the problem that you cannot create Google accounts v
Conceptually it sounds a lot like ZeroCoin (not in implementation)?
I'm not really convinced miner cartels that try to exclude transactions are
likely to be a big deal, but such schemes could I suppose be kept in a back
pocket in case one day I'm proven wrong.
On Wed, May 15, 2013 at 6:39 PM, Gr
I'm all for funding of Bitcoin development, but I suggest talking to Gavin
to find out what efforts would be the biggest win right now. I don't see
why separating wallet code from the main Bitcoin process would increase
node count, as the cost of running the node is almost all in keeping up
with tr
Indeed, that has been proposed but it's a dumb idea and I'm very sceptical
it will go anywhere. Certainly no decision was made. The arguments for it
are based on some quite faulty thinking about economics. Double spend
notifications have been proposed a long time ago, I believe Matt has
indicated
Bitcoinj already has such chain id's and we use standard Java style reverse
DNS names: org.bitcoin.main, etc. If we want a more global naming system
that seems like a good compromise between uniqueness and readability.
On 20 May 2013 19:45, "Jeff Garzik" wrote:
> On Mon, May 20, 2013 at 7:59 PM,
On Thu, Jun 6, 2013 at 2:19 AM, Peter Vessenes wrote:
> So, this
> http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1
> article got posted today, noting that FinCEN thinks irrevocable payments
> are money laundering tools.
>
That's not how I read it, I don't
I'm pleased to announce the release of bitcoinj 0.9, a Java library for
working with the Bitcoin protocol. Both simplified and full verification
are supported. BitcoinJ has been used to create everything from end-user
wallet apps to network crawlers to SatoshiDice.
To get bitcoinj 0.9, check out o
It's not a bug (although there was recently a change to make bitcoind/qt
always send this field anyway).
I don't know where Amir is going with BIP 60. Version messages have always
been variable length. There's nothing inherent in the Bitcoin protocol that
says all messages are fixed length, indeed
a 1 byte flag
> needs to be optional anyway.
>
> --
> *From:* Mike Hearn
> *To:* Turkey Breast
> *Cc:* Bitcoin Dev
> *Sent:* Tuesday, June 18, 2013 9:48 PM
> *Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version message
>
icating it should. Nowhere was this
> written. It doesn't help other implementations to have an unclear behaviour
> that depends on some magic from one implementation.
>
> --
> *From:* Mike Hearn
> *To:* Turkey Breast
> *Cc:* "bitcoin-development
in dev community, so let me know if I’m horribly violating
> any mailing list etiquette. 😊
>
> *From:* Mike Hearn
> *Sent:* Wednesday, June 19, 2013 7:43 AM
> *To:* Turkey Breast
> *Cc:* bitcoin-development@lists.sourceforge.net
>
> Bitcoin-Qt on master does sen
ery field change, the protocol version should be upgraded.
>
> Now that fRelayTxes is part of the protocol, the version number should be
> upgraded to reflect this fact.
>
> --
> *From:* Mike Hearn
> *To:* Paul Lyon
> *Cc:* Turkey Breast ; "
Agree with Jeremy and once the payment protocol work is further along I'd
like to see us define an extension that lets you send payment requests
containing public keys+chain codes, so further payments can be made
push-style with no recipient interaction (e.g. for repeated billing). How
apps choose
Sure but why not do that when there's an actual new field to add? Does
anyone have a proposal for a feature that needs a new version field at the
moment? There's no point changing the protocol now unless there's actually
a new field to add.
Anyway I still don't see why anyone cares about this issu
flag added in BIPXX is not present.
>
> Your argument is that this complexity is already there so why not preserve
> it. I think eliminating complexity (that has no benefit) strengthens the
> system.
>
> *Tamás Blummer*
> http://bitsofproof.com
> <http://bitsofproof.com/>
#x27;t handle it need to fix their code anyway.
So I have a slight preference for keeping things the way they are, it keeps
things flexible for future and costs nothing.
On Thu, Jun 20, 2013 at 11:06 AM, Pieter Wuille wrote:
> On Thu, Jun 20, 2013 at 09:36:40AM +0200, Mike Hearn wrote:
&g
bly the software should penalise
> hosts which do that.
>
> What's the big deal to update the protocol version number from 70001 to
> 70002? It's not like we'll run out of integers. The field has now gone from
> optional to required now anyway - that's a behav
it makes no assumptions based on that
>> which is a mistake (new clients can broadcast older version messages that
>> don't have all the fields required). Probably the software should penalise
>> hosts which do that.
>>
>> What's the big deal to update the prot
Indeed, and for a higher level answer, see here:
https://en.bitcoin.it/wiki/Contracts
On Fri, Jun 21, 2013 at 6:03 AM, Patrick Strateman
wrote:
> It's well answered by this stack exchange question.
>
> http://bitcoin.stackexchange.com/questions/2025/what-is-txins-sequence
>
>
> On 06/20/2013 0
> There were a number of issues with it at the time, in
> particular the frequent deadlocks— though Mike was saying that those
> should be fixed.
Yes. There were a number of lock cycles that didn't cause issues so
much when traffic was lower and as Bitcoin got more popular it became
a critical pro
> Arguments in favor of retaining Bitcoin-Qt/bitcoind default:
> * More field experience, code review and testing on desktop than others
I'm hoping that if we start promoting alternative wallets their dev
communities will get larger. Most bitcoinj code is peer reviewed, but
not to the same extent
I suspect what you saw is mining nodes restarting and clearing their
mempools out rather than an explicit policy of replace by fee.
On Fri, Jun 28, 2013 at 12:09 PM, John Dillon
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Fri, Jun 28, 2013 at 9:05 AM, Mike
Sounds like we have consensus, Saivann, shall we do it?
I'm also going to ask Theymos again to relax the newbie restrictions
for the alt client forums. It's probably too hard to get support at
the moment and "email jim" doesn't scale at all.
On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen wrote:
s possible.
> > + Failing that people are directed first to
> bitcoin.stackchange.com <http://bitcoin.stackchange.com>
> >(I have a notification set up for the 'multibit' keyword.
> > + Then finally users are directed to the github is
6s are correct
> for instance. This would increase the maximum number of
> downloads we could cope with.
>
>
> On Tue, Jul 9, 2013, at 11:36 AM, Mike Hearn wrote:
> > Modern Java versions let you bundle the app with a stripped down JVM. I
> > don't know if Jim
ne it's better than nothing.
On Tue, Jul 9, 2013 at 1:04 PM, Mike Hearn wrote:
> How many downloads/day do we see currently? I think you said it's on the
> order of a few thousand, so nowhere near 30k I'd guess. Anyway I can mirror
> it if we need to.
>
> The Ja
SourceForge has a horrible UI and blocks some countries. It also exposes us
to a large and potentially hackable mirror network. Whilst we're not
bandwidth constrained on our own servers, let's try and keep using them.
On Tue, Jul 9, 2013 at 4:06 PM, Jeff Garzik wrote:
> On Tue, Jul 9, 2013 at 1
That's true - we could serve new users off our own servers and auto updates
off SF.net mirrors, potentially.
On Tue, Jul 9, 2013 at 4:57 PM, Daniel F wrote:
> on 07/09/2013 10:28 AM Mike Hearn said the following:
> > SourceForge has a horrible UI and blocks some countries. I
401 - 500 of 877 matches
Mail list logo
