> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
es for it to fail.
This is extremely simple-minded logic that encourages ephemeral, junk
data in the blockchain. Not a scalable approach.
The implication is to put the communications medium in the blockchain
itself, which is wrong.
--
Jeff Garzik
Bitcoin core developer and open source evang
o
run into problems if you rely 100% on seeds, always.
Further, there are multiple seeds so that we are not impacted if a
couple seeds malfunction or die. All bitcoin apps must take this into
account.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.
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.
arted:
> 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
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.
consistent rude behavior gets the boot.
b) anything related to decentralization, consensus, proven data
structures or crypto is on-topic
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
---
ith 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
d be an interesting experiment.
> Maybe BitTorrent's µTP protocol could be leveraged.
>
> On Tue, May 20, 2014 at 12:17 PM, Jeff Garzik wrote:
>> Yes, i spec'd out the UDP traversal of the P2P protocol. It seems
>> reasonable especially for "inv" messages.
&g
tatic" rule a
bit for significant BIP bugs, or harmless maintenance of
links-to-resources.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
"Accelerate
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.sourc
lications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourcefor
e problem.
>
> I'll try to investigate further this afternoon once I get out of
> meetings/meetings prep.
>
> Toshi
>
>
>
> On Tue, Jun 3, 2014 at 9:43 AM, Jeff Garzik wrote:
>>
>> I think I see the problem.
>>
>>
>> On Mon, Jun 2, 2014
ide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> Bitcoin-development mailing list
>
We are considering pulling in https://github.com/bitcoin/bitcoin/pull/2340
"Discourage fee sniping with nLockTime"
Comments from other wallet implementors in particular are welcomed.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://
.
Stack trace of each thread + multi-threaded core dump are a good
start.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
Learn Graph Databases - Download FREE
d away from "getwork" years ago.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph D
--
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Explorat
e strings at the last minute
in a language maintainers don't know well.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
HPCC Systems Open Source Big Data Platfo
st Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
On Wed, Jun 18, 2014 at 5:23 AM, Wladimir wrote:
> Anyhow -- back to the original proposal. I'm fine with setting aside
> part of the service bit space for experiments.
ACK
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https:/
aveats noting in BOLD language
that this field is informational, and should not be relied upon for
accounting/auditing purposes.
It just seems like a statistic that everyone has an incentive to exaggerate.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.
elopment mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-
I'm inclined to merge https://github.com/bitcoin/bitcoin/pull/2340
which sets nLockTime on wallet-created transactions by default. I
think this is good practice for wallets, long term.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpa
---
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE
the same block (or itself).
This would be a good invalid-block test to add to the test suite. Any
volunteers?
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
Want f
ncremental process
> and there are certainly many quirks I'm not aware of. I hope that
> together we will soon be able to fill in the missing gaps.
Firstly, it is an excellent document, and it should be useful in
educating others.
I do agree that "specification" is not a good w
swers, but it does seem valuable IMO to
* Prevent users from accidentally sending to an "expired" TxOut/pkh.
This happens in the field.
* Discourage address reuse
* Enable sites that generate lots of keys to rotate ancient keys off
their core systems. (HD wallets mitigate this)
--
Jef
veral deployed use cases where you are provided/request an
address, an API provides one, and one or more incoming payments arrive
as the user sends them over minutes/hours/days/weeks.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. http
e's somewhere that's using addresses,
> that's somewhere we will eventually need to upgrade to use BIP70 instead.
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
---
ing payment stream from, e.g. Eligius to coinbase
* deposit addresses and deposit situations
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
Want fast and easy a
lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> --
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black D
7;d be identical.
>
> Places like protocols or APIs that require a piece of text and cannot handle
> a piece of binary data could be retrofitted into the new world by accepting
> base58 encoded PaymentRequest's. This would be kind of silly because it's
> fundamentally b
t rid of the \u0000 problem.
>
>
> On 07/15/2014 05:17 PM, Jeff Garzik wrote:
>> Unicode guarantees that null-terminated strings still work. U+
>> terminates a unicode (or C) string. strlen() gets the string byte
>> count. mbstowcs() gets the character count
mputers are offline.
If you have negotiated HD wallet details, you can use a new address
every time, as mentioned.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-
in the middle could still yield incorrect results.
>
> <https://github.com/mikehearn/bips/commit/6058b92f5d9804ee4104649f53afc2fa53248c81?short_path=35c7795#implementation>
> Implementation
>
> https://github.com/bitcoin/bitcoin/pull/4351/files
>
>
> ---
BIP 35 (mempool command) are not apt, as
>> miners and full nodes treat "mempool" returned data just like any other
>> randomly solicited "tx" command on the network. Unlike "mempool" cmd, this
>> "getutxos" cmd proffers post-verification tr
On Wed, Jul 16, 2014 at 1:56 PM, Jeremy wrote:
> Right now, this could be expressed multiple ways (ie, using an op_dup if
> then else chain) , but all would incur additional costs in terms of
> complicated control flows. Instead, I would propose:
Can you quantify "additional costs in terms of com
the group #1, groups then reindex after
> deletion (maybe the group was useful base class).
> etc...
> multisig check perm groups (checks if any groups on stack are valid from
> script)
>
>
> or even something like adding a little SAT scripting language with an eval.
&g
ot; technical solution, but it remains to be seen how much we
engineers can really do to make life fair. Making transaction
selection a bit more independent from hashpower seems one step. There
are several other proposals floating about.
--
Jeff Garzik
Bitcoin core developer and open source evan
Before they got traction, yes. But he projected a bit, as anyone
could, to see the trend.
On Thu, Jul 17, 2014 at 1:22 PM, slush wrote:
>
> On Thu, Jul 17, 2014 at 6:14 PM, Jeff Garzik wrote:
>>
>> Historical note: On one hand, Satoshi seemed to dislike the early
>>
;s agreement to postpone it as long as possible, to help make sure
>> the distribution of coins was as even as possible. Indeed this predated
>> pooled mining.
>>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-
On Thu, Jul 17, 2014 at 6:46 PM, Gavin Andresen wrote:
> I'd encourage you to code up a prototype first (or at the same time), in
> whatever programming language / networking library you're most familiar
> with.
+1
> Maybe not even using the existing p2p protocol; there could be a mining-only
>
des the better ability to predict what is in an
upcoming block.
And the flip side of that, such predictions are never perfect. Need
to make sure the fallback case, while undoubtedly more costly than the
Fast Path, is not overly painful.
--
Jeff Gar
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-devel
de in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> ___
11846
The version message helpfully tells me my own IP address but not theirs ;p
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
Infragistics Professional
eclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin c
tion expiration, the
desire to cap the mempool ram usage, scalability, DoS prevention, ...
mempool ties a lot together.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
---
looking
back two or three TXs deep at coin age -- which I admit is an interesting
metric.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
Infragistics Professional
e and much debate. :)
For the moment, simply capping the mempool's size at each local node is a
much more reachable goal. Capping, then, implies some culling policy. In
general, bitcoind Tx mempool size is rather open ended, and that needs
sorting out.
--
Jeff Garzik
Bitcoin core developer
_
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
---
t anyway.
>
>
> On Wed, Aug 6, 2014 at 2:55 PM, Jeff Garzik wrote:
>
>> ...and existing users and uses of nLockTime suddenly become worthless,
>> breaking payment channel refunds and other active uses of nLockTime.
>>
>> You cannot assume the user is around to r
je3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP
> RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2
> sJKN
> =oPSo
> -END PGP SIGNATURE-
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6
>> //qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c
>> 4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba
>> 1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08
Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
>
only if the external
services are at the same IP address that is being advertised.
This is not a fully baked proposal by any means, but more of a trial
balloon to get discussion moving.
There is no need to implement all services inside bitcoind...
--
Jeff Garzik
Bitcoin core developer and open s
sy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _
n Fri, Aug 8, 2014 at 6:01 AM, Mike Hearn wrote:
> What's wrong
> with the existing mechanism exactly?
It would be wrong to add NODE_INSIGHT, NODE_ELECTRUM_SERVER, etc. bits
even though you do have useful bitcoin-related APIs that exist on the
same system as bitcoind.
--
Jeff Gar
s.
>
> Additionally, nothing in this spec requires that a local bitcoind be
> running. What stops someone from advertising just NODE_EXTENDED_SERVICES and
> nothing else? I don't think a generic service advertisement mechanism is a
> bad thing to have, by the way, just pointing o
placement for jgarzik's proposal.
>
> Something like `getutxos` or this proposal could be implemented as an
> external application or script, instead of having to integrate
> everything into bitcoind.
Seconded. Command plug-ins and such seem like an idea worth exploring.
We don&#x
nternally. PR #4599 tries to lead by example:
https://github.com/bitcoin/bitcoin/pull/4599
A P2P service would be a slightly different sort of plug-in.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.
n do the basic P2P protocol could then be extended with not
> much code to get a multiplexed stream of messages from different clients.
>
> An additional standalone program can then bridge this mechanism to running a
> shell command for particular messages, though given the history of s
saction
publish-to-outside-world time are the same, even though they often
are.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
Want fast and easy access to al
tware that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sour
evelopment mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
---
---
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bi
-kernel-git-repositories-add-2-factor-authentication
As a first step, one possibility is putting the primary repo on
bitcoin.org somewhere, and simply mirroring that to github for each
push.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com
gt; Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _____
On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd wrote:
> On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik wrote:
>>Encryption is of little value if you may deduce the same information
>>by observing packet sizes and timings.
>
> That is simply incorrect. The resources requir
When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourcefo
ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
nd boring
signed challenge process, for all we know, "sipa" is a supercomputing
cluster of 500 gnomes.
The point is, the "online entity known as Satoshi" is the relevant
fingerprint. That is easily established without any in-person
meetings.
--
Jeff Garzik
Bitcoin core d
ot of PGP hating these days but this comment doesn't
> necessarily apply to every situation.
>
>
>
>> On Sep 15, 2014, at 9:08 AM, Jeff Garzik wrote:
>>
>>> On Mon, Sep 15, 2014 at 3:23 AM, Thomas Zander
>>> wrote:
>>> Any and all PGP related howtos wi
We are slowly applying a consistent style to the C++ source, via
clang-format (LLVM) and $repo/src/.clang-format.
If you have a patch that is difficult to apply to the tree due to
reformatting, simply apply clang-format and then rediff.
--
Jeff Garzik
Bitcoin core developer and open source
Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-
The whole issue is a troll, and I'm afraid you got sucked in.
There are no plans to add a blacklist to Bitcoin Core.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpa
mailing list anyway, although if I had a different opinion I
>> certainly hope I would still send this message.
>>
>> Thank you.
>>
>> - Bryan
>> http://heybryan.org/
>> 1 512 203 0507
>
> ------
> ___
> Bitcoin-dev
his is unlikely for well informed and
well prepared market participants.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
ment mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
hub.com/jgarzik/rpcsrv
PR #2844 @ https://github.com/bitcoin/bitcoin/pull/2844
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
; Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
gular-Block-Times.html
>
> Thanks,
> Rusty.
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourcefo
problems and confusion down the road.
Though I ACK'd the change, my general preference remains to disconnect
TX and block version.
--
Jeff Garzik
Bitcoin core developer and open source evang
e learn could define a hard fork or a better
>> chain we migrate to as discussed by blockstream.
>>
>> Tamas Blummer
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sour
wallets have obtained a reasonable
> user base and are stable.
>
>
>
> ------
>
>
e
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.ne
stg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
Bi
On Wed, Dec 10, 2014 at 1:47 AM, Wladimir wrote:
> Concept ACK -> agree with the idea and overall direction, but haven't
> reviewed the code changes nor tested it
>
Concept ACK -> like the idea; the code may need rewriting (or haven't
reviewed).
--
Jeff Garzik
Bitcoi
and-make-it-pretty-and-do-all-the-work.
Some change is in order, gentlemen.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
Download BIRT iHub F-Type - The Free Ent
cations, followed by data structure work, further patches are easy
to review/apply with less impact on unrelated code.
The flow of patches into the tree over time should be examined. Simply
tagging patches as movement-only does not address the described problem at
all.
--
Jeff Garzik
Bitcoin core dev
disincentives for working on other
types of patches.
On Mon, Dec 15, 2014 at 4:19 PM, Cory Fields wrote:
>
> On Mon, Dec 15, 2014 at 2:35 PM, Jeff Garzik wrote:
> > On Mon, Dec 15, 2014 at 1:42 PM, Cory Fields
> wrote:
> >>
> >> That's exactly what happened d
here.
While recent code movement commits themselves are individually ACK-worthy,
professionally executed and moving towards a positive goal, I think the
project could strike a better balance when it comes to disruptive cosmetic
changes, a balance that better encourages developers to work o
tcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
---
ought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
>
Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourcefor
wer latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.so
me the line is blurred between which of those
> are security considerations vs performance considerations.
>
> Richard
>
> On 19 January 2015 at 19:09, Jeff Garzik wrote:
>
>> Text formats such as XML or JSON are far less deterministic, are more
>> loosely specified, h
--
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Incre
1 - 100 of 412 matches
Mail list logo
