[Bitcoin-development] Why are we bleeding nodes?

[Mike Hearn]

At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
still falling:

http://getaddr.bitnodes.io/dashboard/chart/?days=60

I know all the reasons why people *might* stop running a node (uses too
much disk space, bandwidth, lost interest etc). But does anyone have any
idea how we might get more insight into what's really going on? It'd be
convenient if the subVer contained the operating system, as then we could
tell if the bleed was mostly from desktops/laptops (Windows/Mac), which
would be expected, or from virtual servers (Linux), which would be more
concerning.

When you set up a Tor node, you can add your email address to the config
file and the Tor project sends you emails from time to time about things
you should know about. If we did the same, we could have a little exit
survey: if your node disappears for long enough, we could email the
operator and ask why they stopped.

[Ricardo Filipe]

phasing out of bitcoinqt into spv wallets?

2014-04-07 12:34 GMT+01:00 Mike Hearn <***@plan99.net>:
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:
>
> http://getaddr.bitnodes.io/dashboard/chart/?days=60
>
> I know all the reasons why people might stop running a node (uses too much
> disk space, bandwidth, lost interest etc). But does anyone have any idea how
> we might get more insight into what's really going on? It'd be convenient if
> the subVer contained the operating system, as then we could tell if the
> bleed was mostly from desktops/laptops (Windows/Mac), which would be
> expected, or from virtual servers (Linux), which would be more concerning.
>
> When you set up a Tor node, you can add your email address to the config
> file and the Tor project sends you emails from time to time about things you
> should know about. If we did the same, we could have a little exit survey:
> if your node disappears for long enough, we could email the operator and ask
> why they stopped.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[Andreas Schildbach]

They're _not_ phasing out into SPV wallets from what I can say. At
around the 24th of February, there has been a sharp change of the
"current installs" graph of Bitcoin Wallet. That number used to grow at
about 20.000 per month. After that date until now, it just barely moves
horizontal.

My guess is that a large number of users have lost interest after they
lost their money in MtGox. The 24th of February coincides with the
"final" shutdown, according to

http://en.wikipedia.org/wiki/Mt._Gox#February_2014_shutdown_and_bankruptcy


On 04/07/2014 02:17 PM, Ricardo Filipe wrote:
> phasing out of bitcoinqt into spv wallets?
>
> 2014-04-07 12:34 GMT+01:00 Mike Hearn <***@plan99.net>:
>> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
>> still falling:
>>
>> http://getaddr.bitnodes.io/dashboard/chart/?days=60
>>
>> I know all the reasons why people might stop running a node (uses too much
>> disk space, bandwidth, lost interest etc). But does anyone have any idea how
>> we might get more insight into what's really going on? It'd be convenient if
>> the subVer contained the operating system, as then we could tell if the
>> bleed was mostly from desktops/laptops (Windows/Mac), which would be
>> expected, or from virtual servers (Linux), which would be more concerning.
>>
>> When you set up a Tor node, you can add your email address to the config
>> file and the Tor project sends you emails from time to time about things you
>> should know about. If we did the same, we could have a little exit survey:
>> if your node disappears for long enough, we could email the operator and ask
>> why they stopped.
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees_APR
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
>

[Mike Hearn]

>
> My guess is that a large number of users have lost interest after they
> lost their money in MtGox. The 24th of February coincides with the
> "final" shutdown


Sigh. It would not be surprising if MtGox has indeed dealt the community a
critical blow in this regard. TX traffic is down since then too:

https://blockchain.info/charts/n-transactions-excluding-popular?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

Judging from comments and the leaked user db, it seems a lot of well known
people lost money there (not me fortunately). I wish I could say people
have learned but from the size of the deposit base at Bitstamp they clearly
have not. A lot of Bitcoin users don't seem to be ready to be their own
bank, yet still want to own some on the assumption everyone else either is
or soon will be. So it's really only a matter of time until something goes
wrong with some large bitbank again, either Bitstamp or Coinbase.

Some days I wonder if Bitcoin will be killed off by people who just refuse
to use it properly before it ever gets a chance to shine. The general
public doesn't distinguish between "Bitcoin users" who deposit with a third
party and the real Bitcoin users who don't.

[Mike Hearn]

Indeed, fully agreed. The only way to really make progress here is to make
the UX of being your own bank not only as good as trusting a third party,
but better.

I've been encouraged by the rise of risk analysis services, but we need to
integrate them into wallets more widely for them to have much impact.
Otherwise people get to pick between a variety of wallets, none of which
have *all* the features they want. And TREZOR is cool, albeit, something
that's going to be for committed users only.



On Mon, Apr 7, 2014 at 4:15 PM, Eric Martindale <***@ericmartindale.com>wrote:

> We need to make it so mind-numbingly simple to "run Bitcoin correctly"
> that the average user doesn't find reasons to do so in the course of normal
> use. Right now, Coinbase and Bitstamp are winning in the user experience
> battle, which technically endanger the user, and by proxy the Bitcoin
> network.
>
> Multi-sig as a default is a start. It won't succeed unless the user
> experience is simply better than trusted third parties, but we need to
> start the education process with the very basic fundamental: trusting a
> third-party with full access to your Bitcoin is just replacing one
> centralized banking system with another.
>
> Eric Martindale
> Developer Evangelist, BitPay
> [phone]
> On Apr 7, 2014 7:05 AM, "Mike Hearn" <***@plan99.net> wrote:
>
>> My guess is that a large number of users have lost interest after they
>>> lost their money in MtGox. The 24th of February coincides with the
>>> "final" shutdown
>>
>>
>> Sigh. It would not be surprising if MtGox has indeed dealt the community
>> a critical blow in this regard. TX traffic is down since then too:
>>
>>
>> https://blockchain.info/charts/n-transactions-excluding-popular?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
>>
>> Judging from comments and the leaked user db, it seems a lot of well
>> known people lost money there (not me fortunately). I wish I could say
>> people have learned but from the size of the deposit base at Bitstamp they
>> clearly have not. A lot of Bitcoin users don't seem to be ready to be their
>> own bank, yet still want to own some on the assumption everyone else either
>> is or soon will be. So it's really only a matter of time until something
>> goes wrong with some large bitbank again, either Bitstamp or Coinbase.
>>
>> Some days I wonder if Bitcoin will be killed off by people who just
>> refuse to use it properly before it ever gets a chance to shine. The
>> general public doesn't distinguish between "Bitcoin users" who deposit with
>> a third party and the real Bitcoin users who don't.
>>
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees_APR
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>

[Eric Martindale]

We need to make it so mind-numbingly simple to "run Bitcoin correctly" that
the average user doesn't find reasons to do so in the course of normal
use. Right now, Coinbase and Bitstamp are winning in the user experience
battle, which technically endanger the user, and by proxy the Bitcoin
network.

Multi-sig as a default is a start. It won't succeed unless the user
experience is simply better than trusted third parties, but we need to
start the education process with the very basic fundamental: trusting a
third-party with full access to your Bitcoin is just replacing one
centralized banking system with another.

Eric Martindale
Developer Evangelist, BitPay
[phone]
On Apr 7, 2014 7:05 AM, "Mike Hearn" <***@plan99.net> wrote:

> My guess is that a large number of users have lost interest after they
>> lost their money in MtGox. The 24th of February coincides with the
>> "final" shutdown
>
>
> Sigh. It would not be surprising if MtGox has indeed dealt the community a
> critical blow in this regard. TX traffic is down since then too:
>
>
> https://blockchain.info/charts/n-transactions-excluding-popular?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
>
> Judging from comments and the leaked user db, it seems a lot of well known
> people lost money there (not me fortunately). I wish I could say people
> have learned but from the size of the deposit base at Bitstamp they clearly
> have not. A lot of Bitcoin users don't seem to be ready to be their own
> bank, yet still want to own some on the assumption everyone else either is
> or soon will be. So it's really only a matter of time until something goes
> wrong with some large bitbank again, either Bitstamp or Coinbase.
>
> Some days I wonder if Bitcoin will be killed off by people who just refuse
> to use it properly before it ever gets a chance to shine. The general
> public doesn't distinguish between "Bitcoin users" who deposit with a third
> party and the real Bitcoin users who don't.
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[Troy Benjegerdes]

I understand the theoretical benefits of multi-sig. But if you want
to make this mind-numbingly simple, do it on the *existing* single-sig.

But why in the world do we not have a *business* that offers bitcoin
wallet insurance? The bitcoin world (and this list) ran around blaming
MtGox and users for being 'stupid' to trust mtgox.

So start a multi-level marketing business that offers *insurance* so
if your bitcoin wallet gets hacked/stolen/whatever, your 'upstream'
or whomever sold you the wallet comes to your house with a new
computer or installs the new wallet software, or whatever, or just
makes it good.

Now, if the **insurance underwriter** decides that multisig will
reduce fraud, and **tests it**, then I'd say we do multi-sig. But right
now we are just a bunch of technology wizards trying to force our own
opinions about what's right and 'simple' for end users without ever
asking the damn end-users.

And then we call the end-users idiots because some scammer calls them
and says "I'm calling from Microsoft and your computer is broke, please
download this software to fix it".

Multi-sig is more magical moon-math that scammers will exploit to con
your grandma out of bitcoin, and then your friends will call her a stupid
luddite for falling for it.

Fix the cultural victim-blaming bullshit and you'll fix the node bleeding
problem.

On Mon, Apr 07, 2014 at 10:15:15AM -0400, Eric Martindale wrote:
> We need to make it so mind-numbingly simple to "run Bitcoin correctly" that
> the average user doesn't find reasons to do so in the course of normal
> use. Right now, Coinbase and Bitstamp are winning in the user experience
> battle, which technically endanger the user, and by proxy the Bitcoin
> network.
>
> Multi-sig as a default is a start. It won't succeed unless the user
> experience is simply better than trusted third parties, but we need to
> start the education process with the very basic fundamental: trusting a
> third-party with full access to your Bitcoin is just replacing one
> centralized banking system with another.
>
> Eric Martindale
> Developer Evangelist, BitPay
> [phone]
> On Apr 7, 2014 7:05 AM, "Mike Hearn" <***@plan99.net> wrote:
>
> > My guess is that a large number of users have lost interest after they
> >> lost their money in MtGox. The 24th of February coincides with the
> >> "final" shutdown
> >
> >
> > Sigh. It would not be surprising if MtGox has indeed dealt the community a
> > critical blow in this regard. TX traffic is down since then too:
> >
> >
> > https://blockchain.info/charts/n-transactions-excluding-popular?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
> >
> > Judging from comments and the leaked user db, it seems a lot of well known
> > people lost money there (not me fortunately). I wish I could say people
> > have learned but from the size of the deposit base at Bitstamp they clearly
> > have not. A lot of Bitcoin users don't seem to be ready to be their own
> > bank, yet still want to own some on the assumption everyone else either is
> > or soon will be. So it's really only a matter of time until something goes
> > wrong with some large bitbank again, either Bitstamp or Coinbase.
> >
> > Some days I wonder if Bitcoin will be killed off by people who just refuse
> > to use it properly before it ever gets a chance to shine. The general
> > public doesn't distinguish between "Bitcoin users" who deposit with a third
> > party and the real Bitcoin users who don't.
> >
> >
> > ------------------------------------------------------------------------------
> > Put Bad Developers to Shame
> > Dominate Development with Jenkins Continuous Integration
> > Continuously Automate Build, Test & Deployment
> > Start a new project now. Try Jenkins in the cloud.
> > http://p.sf.net/sfu/13600_Cloudbees_APR
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >

> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR

> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' ***@hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop

Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash

[kjj]

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.

I mean no offense, and I don't mean to pick on you. Your post stuck out
while I was reading. Secure multi-sig is what we all want, but wanting
apparently isn't enough to make it happen.

Other random notes from reading this 50+ post thread:

Perhaps we should have a config flag to prevent a node from serving IBD
to new nodes. IBD crushes marginal machines, particularly those with
spinning disks. This has been extensively discussed elsewhere.

The ideal IBD hosts are serving the blockchain out of a RAM disk. Is
there any interest in setting up a network of volunteers to host
expensive servers with fast connections? It doesn't look too terribly
difficult to figure out when a node has stopped asking for blocks in
bulk, so we could add another config flag to eject nodes once they are
done booting.

Even ignoring IBD, I think that we are gradually outgrowing cheapass
hosting options. Personally, I long ago gave up on answering forum
questions about running nodes on virtual servers and VPSs. It is
certainly still possible to run bitcoind on small boxes, but it isn't
trivial any more. (Anyone running on less than my Athlon XP 1800+ with
896 MB RAM?) If we want those nodes back, we need to optimize the hell
out of the memory use, and even that might not be enough.


Eric Martindale wrote:
>
> We need to make it so mind-numbingly simple to "run Bitcoin correctly"
> that the average user doesn't find reasons to do so in the course of
> normal use. Right now, Coinbase and Bitstamp are winning in the user
> experience battle, which technically endanger the user, and by proxy
> the Bitcoin network.
>
> Multi-sig as a default is a start. It won't succeed unless the user
> experience is simply better than trusted third parties, but we need to
> start the education process with the very basic fundamental: trusting
> a third-party with full access to your Bitcoin is just replacing one
> centralized banking system with another.
>
>

[Mike Hearn]

>
> 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 wallet
there's BitGo and greenaddress.it already, though I think their risk
analysis is just sending you an SMS code. I wrote up an integration plan
for bitcoinj a few days ago:

https://groups.google.com/forum/#!topic/bitcoinj/Uxl-z40OLuQ

but guess what? It's quite complicated. As with all these features.

[Wendell]

On that note, I think we have every possibility to make desktop and mobile wallets mind-numbingly simple -- and perhaps even do one better. Is this now a community priority? If so, I would really appreciate some additional contributors to Hive!

https://github.com/hivewallet/hive-osx
https://github.com/hivewallet/hive-android

-wendell

hivewallet.com | twitter.com/hivewallet | pgp 0x8C498718
twitter.com/bitcoinbookclub | campbitcoin.hivewallet.com

On Apr 7, 2014, at 9:15 PM, Eric Martindale wrote:

> We need to make it so mind-numbingly simple to "run Bitcoin correctly" that the average user doesn't find reasons to do so in the course of normal use. Right now, Coinbase and Bitstamp are winning in the user experience battle, which technically endanger the user, and by proxy the Bitcoin network.
>
> Multi-sig as a default is a start. It won't succeed unless the user experience is simply better than trusted third parties, but we need to start the education process with the very basic fundamental: trusting a third-party with full access to your Bitcoin is just replacing one centralized banking system with another.

[Wladimir]

On Wed, Apr 9, 2014 at 12:38 PM, Wendell <***@hivewallet.com> wrote:

> On that note, I think we have every possibility to make desktop and mobile
> wallets mind-numbingly simple -- and perhaps even do one better. Is this
> now a community priority? If so, I would really appreciate some additional
> contributors to Hive!
>
>
How does that relate to the nodes issue?

Would packaging an optional bitcoind with your wallet be an option, which
is automatically managed in the background, so that users can run a full
node if they want?

Wladimir

[Tom Harding]

On 4/7/2014 7:05 AM, Mike Hearn wrote:
> Some days I wonder if Bitcoin will be killed off by people who just
> refuse to use it properly before it ever gets a chance to shine. The
> general public doesn't distinguish between "Bitcoin users" who deposit
> with a third party and the real Bitcoin users who don't.
>

A Mt-Gox-scale incident was inevitable and there are probably more hard
lessons in the future. But it has made bitcoin much better already.
I'm referring to things like malleability fixes, cleaning house at the
foundation, and public education (hard as the lesson was). A lot more
people than before understand the distinction you're making, and they
are sharing the lesson.

[Jameson Lopp]

I'm glad to see that I'm not the only one concerned about the consistent dropping of nodes. Though I think that the fundamental question should be: how many nodes do we really need? Obviously more is better, but it's difficult to say how concerned we should be without more information. I posted my thoughts last month: http://coinchomp.com/2014/03/19/bitcoin-nodes-many-enough/

I have begun working on my node monitoring project and will post updates if it results in me gaining any new insights about the network.

- Jameson

On 04/07/2014 07:34 AM, Mike Hearn wrote:
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:
>
> http://getaddr.bitnodes.io/dashboard/chart/?days=60
>
> I know all the reasons why people *might* stop running a node (uses too
> much disk space, bandwidth, lost interest etc). But does anyone have any
> idea how we might get more insight into what's really going on? It'd be
> convenient if the subVer contained the operating system, as then we could
> tell if the bleed was mostly from desktops/laptops (Windows/Mac), which
> would be expected, or from virtual servers (Linux), which would be more
> concerning.
>
> When you set up a Tor node, you can add your email address to the config
> file and the Tor project sends you emails from time to time about things
> you should know about. If we did the same, we could have a little exit
> survey: if your node disappears for long enough, we could email the
> operator and ask why they stopped.
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[Pieter Wuille]

On Mon, Apr 7, 2014 at 2:19 PM, Jameson Lopp <***@gmail.com> wrote:
> I'm glad to see that I'm not the only one concerned about the consistent dropping of nodes. Though I think that the fundamental question should be: how many nodes do we really need? Obviously more is better, but it's difficult to say how concerned we should be without more information. I posted my thoughts last month: http://coinchomp.com/2014/03/19/bitcoin-nodes-many-enough/

In my opinion, the number of full nodes doesn't matter (as long as
it's enough to satisfy demand by other nodes).

What matters is how hard it is to run one. If someone is interesting
in verifying that nobody is cheating on the network, can they, and can
they without significant investment? Whether they actually will
depends also no how interesting the currency and its digital transfers
are.

> On 04/07/2014 07:34 AM, Mike Hearn wrote:
>> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
>> still falling:
>>
>> http://getaddr.bitnodes.io/dashboard/chart/?days=60

My own network crawler (which feeds my DNS seeder) hasn't seen any
significant drop that I remember, but I don't have actual logs. It's
seeing around 6000 "well reachable nodes" currently, which is the
highest number I've ever seen (though it's been around 6000 for quite
a while now).

--
Pieter

[Mike Hearn]

>
> In my opinion, the number of full nodes doesn't matter (as long as
> it's enough to satisfy demand by other nodes).
>

Correct. Still, a high number of nodes has a few other benefits:

1) The more nodes there are, the cheaper it should be to run each one,
given that the bandwidth and CPU for serving the chain will be spread over
more people.

2) It makes Bitcoin *seem* bigger, more robust and more decentralised,
because there are more people uniting to run it. So there's a psychological
benefit.

Also, we don't have a good way to measure capacity vs demand at the moment.
Whether we have enough capacity is rather a shot in the dark right now.


> What matters is how hard it is to run one.
>

Which is why I'm interested to learn the reason behind the drop. Is it
insufficient interest, or is running a node too painful?

For this purpose I'd like to exclude people running Bitcoin Core on laptops
or non-dedicated desktops. I don't think full nodes will ever make sense
for consumer wallets again, and I see the bleeding off of those people as
natural and expected (as Satoshi did). But if someone feels it's too hard
to run on a cheap server then that'd concern me.


> My own network crawler (which feeds my DNS seeder) hasn't seen any
> significant drop


It would be good to explain the difference, but I suspect your definition

[Jameson Lopp]

On 04/07/2014 08:26 AM, Pieter Wuille wrote:
> In my opinion, the number of full nodes doesn't matter (as long as
> it's enough to satisfy demand by other nodes).

I agree, but if we don't quantify "demand" then we are practically blind. What is the plan? To wait until SPV clients start lagging / timing out because their requests cannot be handled by the nodes?

For all I know, the network would run just fine on 100 nodes. But not knowing really irks me as an engineer.

- Jameson

[Isidor Zeuner]

> >
> > In my opinion, the number of full nodes doesn't matter (as long as
> > it's enough to satisfy demand by other nodes).
> >
>
> Correct. Still, a high number of nodes has a few other benefits:
>
> 1) The more nodes there are, the cheaper it should be to run each one,
> given that the bandwidth and CPU for serving the chain will be spread over
> more people.
>
> 2) It makes Bitcoin *seem* bigger, more robust and more decentralised,
> because there are more people uniting to run it. So there's a psychological
> benefit.
>

Psychological benefit vs. effective benefit involves the danger of
destroying trust in the Bitcoin network when there are hard facts for
non-robustness while the node number looks big. Therefore, it may make
sense to establish better metrics.

> Also, we don't have a good way to measure capacity vs demand at the moment.
> Whether we have enough capacity is rather a shot in the dark right now.
>
>
> > What matters is how hard it is to run one.
> >
>
> Which is why I'm interested to learn the reason behind the drop. Is it
> insufficient interest, or is running a node too painful?
>
> For this purpose I'd like to exclude people running Bitcoin Core on laptops
> or non-dedicated desktops. I don't think full nodes will ever make sense
> for consumer wallets again, and I see the bleeding off of those people as
> natural and expected (as Satoshi did). But if someone feels it's too hard
> to run on a cheap server then that'd concern me.
>

In my opinion, the characteristic of being able to make use of
non-dedicated nodes should be regarded as an advantage of the Bitcoin
protocol, and not something to get rid of. Nodes being able to
contribute this way may lead to even more robustness than
decentralization alone, as they can do so without exposing a fixed
address which could be attacked.

Best regards,

Isidor

[Gregory Maxwell]

On Mon, Apr 7, 2014 at 4:34 AM, Mike Hearn <***@plan99.net> wrote:
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:

FWIW, A few months before that we had even less than 8500 by the bitnodes count.

Bitcoin.org recommends people away from running Bitcoin-QT now, so I'm
not sure that we should generally find that trend surprising.

[Gregory Maxwell]

On Mon, Apr 7, 2014 at 6:50 AM, Gregory Maxwell <***@gmail.com> wrote:
> FWIW, A few months before that we had even less than 8500 by the bitnodes count.

Gah, accidentally send.... I wanted to continue here that it was less
than 8500 and had been falling pretty consistently for months,
basically since the bitcoin.org change. Unfortunately it looks like
the old bitnodes.io data isn't available anymore, so I'm going off my
memory here.

The Bitnodes counts have always been somewhat higher than my or sipa's
node counts too, fwiw.

[Jameson Lopp]

The Bitnodes project updated their counting algorithm a month or so ago. It used to be slower and less accurate - prior to their update, it was reporting in excess of 100,000 nodes.

- Jameson

On 04/07/2014 09:53 AM, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 6:50 AM, Gregory Maxwell <***@gmail.com> wrote:
>> FWIW, A few months before that we had even less than 8500 by the bitnodes count.
>
> Gah, accidentally send.... I wanted to continue here that it was less
> than 8500 and had been falling pretty consistently for months,
> basically since the bitcoin.org change. Unfortunately it looks like
> the old bitnodes.io data isn't available anymore, so I'm going off my
> memory here.
>
> The Bitnodes counts have always been somewhat higher than my or sipa's
> node counts too, fwiw.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[Gregory Maxwell]

On Mon, Apr 7, 2014 at 6:58 AM, Jameson Lopp <***@gmail.com> wrote:
> The Bitnodes project updated their counting algorithm a month or so ago. It used to be slower and less accurate - prior to their update, it was reporting in excess of 100,000 nodes.

Nah. It reported multiple metrics. The "100,000" number was an mostly
useless metric that just counted the number of distinct addr messages
floating around the network, which contains a lot of junk. They also
reported an actual connectable node count previously and while they
may have tweaked things here and there as far as I can tell it has
been consistent with the numbers they are using in the headlines now.

[Jesus Cea]

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.

--
Jesús Cea Avión _/_/ _/_/_/ _/_/_/
***@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
Twitter: @jcea _/_/ _/_/ _/_/_/_/_/
jabber / xmpp:***@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

[Justus Ranvier]

On 04/07/2014 11:34 AM, Mike Hearn wrote:
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:
>
> http://getaddr.bitnodes.io/dashboard/chart/?days=60
>
> I know all the reasons why people *might* stop running a node (uses too
> much disk space, bandwidth, lost interest etc). But does anyone have any
> idea how we might get more insight into what's really going on? It'd be
> convenient if the subVer contained the operating system, as then we could
> tell if the bleed was mostly from desktops/laptops (Windows/Mac), which
> would be expected, or from virtual servers (Linux), which would be more
> concerning.

It doesn't do much good to only focus on the immediate symptoms at the
exclusion of big picture trends. There are three things happening now
that have nothing to do with operating systems.

1. The resource requirements of a full node are moving beyond the
capabilities of casual users. This isn't inherently a problem - after
all most people don't grow their own food, tailor their own clothes, or
keep blacksmith tools handy in to forge their own horseshoes either.

2. The growth of small and medium-sized native Bitcoin businesses is
lagging #1. Native here means their revenue and expenses are both
denominated in BTC. Most business adoption we've seen so far doesn't
actually handle bitcoins themselves. They use Bitcoin as a payment
method whose processing they outsource.

Contributing to this is the fact that Bitcoin Core, although it has made
great progress in the 0.9 release, can't be accurately described as
"enterprise ready".

3. The P2P protocol used by the network is broken from an incentive
perspective. Resource usage wouldn't be a problem as long as the users
which consume resources pay for them and the users who provide resources
are compensated, and they communicate via an efficient price discovery
mechanism. Right now there is no obvious way to incorporate price
discovery for bandwidth usage or storage space without a completely new
P2P protocol, and the effectiveness with which progress has been blocked
towards price discovery of transaction fees (the area where it is most
obviously necessary) means that I'm not optimistic that this subject
will ever be effectively addressed by Bitcoin Core.

- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

[Gregory Maxwell]

On Mon, Apr 7, 2014 at 8:45 AM, Justus Ranvier <***@gmail.com> wrote:
> 1. The resource requirements of a full node are moving beyond the
> capabilities of casual users. This isn't inherently a problem - after
> all most people don't grow their own food, tailor their own clothes, or
> keep blacksmith tools handy in to forge their own horseshoes either.

Right now running a full node consumes about $1 in disk space
non-reoccurring and costs a couple cents in power per month.

This isn't to say things are all ducky. But if you're going to say the
resource requirements are beyond the capabilities of casual users I'm
afraid I'm going to have to say: citation needed.

[Jameson Lopp]

I would point to bandwidth as the most important issue to the casual user who runs a node at home. Few casual users have the know-how to set up QoS rules and thus become quite annoyed when their Internet connection is discernibly slowed.

- Jameson

On 04/07/2014 11:53 AM, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 8:45 AM, Justus Ranvier <***@gmail.com> wrote:
>> 1. The resource requirements of a full node are moving beyond the
>> capabilities of casual users. This isn't inherently a problem - after
>> all most people don't grow their own food, tailor their own clothes, or
>> keep blacksmith tools handy in to forge their own horseshoes either.
>
> Right now running a full node consumes about $1 in disk space
> non-reoccurring and costs a couple cents in power per month.
>
> This isn't to say things are all ducky. But if you're going to say the
> resource requirements are beyond the capabilities of casual users I'm
> afraid I'm going to have to say: citation needed.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[Mark Friedenbach]

Right now running a full-node on my home DSL connection (<1Mbps) makes
other internet activity periodically unresponsive. I think we've already
hit a point where resource requirements are pushing out casual users,
although of course we can't be certain that accounts for all lost nodes.

On 04/07/2014 08:53 AM, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 8:45 AM, Justus Ranvier <***@gmail.com> wrote:
>> 1. The resource requirements of a full node are moving beyond the
>> capabilities of casual users. This isn't inherently a problem - after
>> all most people don't grow their own food, tailor their own clothes, or
>> keep blacksmith tools handy in to forge their own horseshoes either.
>
> Right now running a full node consumes about $1 in disk space
> non-reoccurring and costs a couple cents in power per month.
>
> This isn't to say things are all ducky. But if you're going to say the
> resource requirements are beyond the capabilities of casual users I'm
> afraid I'm going to have to say: citation needed.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> .
>

[Gregory Maxwell]

On Mon, Apr 7, 2014 at 9:27 AM, Mark Friedenbach <***@monetize.io> wrote:
> Right now running a full-node on my home DSL connection (<1Mbps) makes
> other internet activity periodically unresponsive. I think we've already
> hit a point where resource requirements are pushing out casual users,
> although of course we can't be certain that accounts for all lost nodes.

That is an implementation issue— mostly one that arises as an indirect
consequence of not having headers first and the parallel fetch, not a
requirements issue.

Under the current bitcoin validity rules it should be completely
reasonable to run a full contributing node with no more than 30 kb/s
inbound (reviving two copies of everything, blocks + tansactions ) and
60 kbit/sec outbound (sending out four copies of everything). (So long
as you're sending out >= what you're taking in you're contributing to
the network's capacity). Throw in a factor of two for bursting, though
not every node needs to be contributing super low latency capacity.

This is absolutely not the case with the current implementation, but
it's not a requirements thing.

[Gregory Maxwell]

On Mon, Apr 7, 2014 at 10:01 AM, Mark Friedenbach <***@monetize.io> wrote:
> On 04/07/2014 09:57 AM, Gregory Maxwell wrote:
>> That is an implementation issue— mostly one that arises as an indirect
>> consequence of not having headers first and the parallel fetch, not a
>> requirements issue.
>
> Oh, absolutely. But the question "why are people not running full
> nodes?" has to do with the current implementation, not abstract
> capabilities of a future version of the bitcoind code base.

The distinction is very important because it's a matter of things we
can and should fix vs things that cannot be fixed except by changing
goals/incentives! Opposite approaches to handling them.

When I read "resource requirements of a full node are moving beyond" I
didn't extract from that that "there are implementation issues that
need to be improved to make it work better for low resource users" due
to the word "requirements".

[Brent Shambaugh]

How difficult would it be to set up a node? Using lots of electricity at
home (if required) could be an issue, but I do have a Webfaction account.


On Mon, Apr 7, 2014 at 12:16 PM, Gregory Maxwell <***@gmail.com> wrote:

> On Mon, Apr 7, 2014 at 10:01 AM, Mark Friedenbach <***@monetize.io>
> wrote:
> > On 04/07/2014 09:57 AM, Gregory Maxwell wrote:
> >> That is an implementation issue-- mostly one that arises as an indirect
> >> consequence of not having headers first and the parallel fetch, not a
> >> requirements issue.
> >
> > Oh, absolutely. But the question "why are people not running full
> > nodes?" has to do with the current implementation, not abstract
> > capabilities of a future version of the bitcoind code base.
>
> The distinction is very important because it's a matter of things we
> can and should fix vs things that cannot be fixed except by changing
> goals/incentives! Opposite approaches to handling them.
>
> When I read "resource requirements of a full node are moving beyond" I
> didn't extract from that that "there are implementation issues that
> need to be improved to make it work better for low resource users" due
> to the word "requirements".
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[Mike Hearn]

It uses ~no electricity, it's not like mining.

The primary resources it needs are disk space and bandwidth, after an
intensive initial day or two of building the database.

Actually, I wonder if we should start shipping (auditable) pre-baked
databases calculated up to the last checkpoint so people can download them
and boot up their node right away. Recalculating the entire thing from
scratch every time isn't sustainable in the long run anyway.


On Mon, Apr 7, 2014 at 7:35 PM, Brent Shambaugh
<***@gmail.com>wrote:

> How difficult would it be to set up a node? Using lots of electricity at
> home (if required) could be an issue, but I do have a Webfaction account.
>
>
> On Mon, Apr 7, 2014 at 12:16 PM, Gregory Maxwell <***@gmail.com>wrote:
>
>> On Mon, Apr 7, 2014 at 10:01 AM, Mark Friedenbach <***@monetize.io>
>> wrote:
>> > On 04/07/2014 09:57 AM, Gregory Maxwell wrote:
>> >> That is an implementation issue— mostly one that arises as an indirect
>> >> consequence of not having headers first and the parallel fetch, not a
>> >> requirements issue.
>> >
>> > Oh, absolutely. But the question "why are people not running full
>> > nodes?" has to do with the current implementation, not abstract
>> > capabilities of a future version of the bitcoind code base.
>>
>> The distinction is very important because it's a matter of things we
>> can and should fix vs things that cannot be fixed except by changing
>> goals/incentives! Opposite approaches to handling them.
>>
>> When I read "resource requirements of a full node are moving beyond" I
>> didn't extract from that that "there are implementation issues that
>> need to be improved to make it work better for low resource users" due
>> to the word "requirements".
>>
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[Gregory Maxwell]

On Mon, Apr 7, 2014 at 10:40 AM, Mike Hearn <***@plan99.net> wrote:
> Actually, I wonder

The actual validation isn't really the problem today. The slowness of
the IBD is almost exclusively the lack of parallel fetching and the
existence of slow peers. And making the signature gate adaptive (and
deploying the 6x faster ECDSA code) would improve that future.

Go grab sipa's headers first branch, it has no problem saturating a
20mbit/sec pipe syncing up.

[Tamas Blummer]

I rather prefer to start with SPV and upgrade to full node, if desired.

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 19:40, Mike Hearn <***@plan99.net> wrote:

>
> Actually, I wonder if we should start shipping (auditable) pre-baked databases calculated up to the last checkpoint so people can download them and boot up their node right away. Recalculating the entire thing from scratch every time isn't sustainable in the long run anyway.
>

[Justus Ranvier]

On 04/07/2014 05:40 PM, Mike Hearn wrote:
> The primary resources it needs are disk space and bandwidth, after
> an intensive initial day or two of building the database.

Check out the kind of hardware causal users are running these days.

The bottleneck is not bulk disk space, but rather IOPS.

Most users don't have spare machines to dedicate to the task of
running a full node, nor is it acceptable for them to not be able to
use their device for other tasks while the node is bootstrapping.

- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

[Arne Brutschy]

> The bottleneck is not bulk disk space, but rather IOPS.

Exactly. I stopped running a full node on both of my desktops machines
in the last month. Both systems were simply becoming very noticeable
(=unbearably) sluggish. I am also running dedicated nodes, which are
fine, but on a desktop latency is a major issue (or, let's say, a
different issue than on a server).

I didn't notice any network latency, but that's hard to judge as our
internet is pants anyway.

Arne

PS: my machines aren't the newest, but still do a stellar job (without
bitcoind running ;)

[Brent Shambaugh]

Okay awesome. It seems like I set up a Litecoin node without knowing it
(because it was like this:
https://bitcointalk.org/index.php?topic=128122.0) I was able to bootstrap
it (https://litecoin.info/).


On Mon, Apr 7, 2014 at 12:40 PM, Mike Hearn <***@plan99.net> wrote:

> It uses ~no electricity, it's not like mining.
>
> The primary resources it needs are disk space and bandwidth, after an
> intensive initial day or two of building the database.
>
> Actually, I wonder if we should start shipping (auditable) pre-baked
> databases calculated up to the last checkpoint so people can download them
> and boot up their node right away. Recalculating the entire thing from
> scratch every time isn't sustainable in the long run anyway.
>
>
> On Mon, Apr 7, 2014 at 7:35 PM, Brent Shambaugh <***@gmail.com
> > wrote:
>
>> How difficult would it be to set up a node? Using lots of electricity at
>> home (if required) could be an issue, but I do have a Webfaction account.
>>
>>
>> On Mon, Apr 7, 2014 at 12:16 PM, Gregory Maxwell <***@gmail.com>wrote:
>>
>>> On Mon, Apr 7, 2014 at 10:01 AM, Mark Friedenbach <***@monetize.io>
>>> wrote:
>>> > On 04/07/2014 09:57 AM, Gregory Maxwell wrote:
>>> >> That is an implementation issue-- mostly one that arises as an indirect
>>> >> consequence of not having headers first and the parallel fetch, not a
>>> >> requirements issue.
>>> >
>>> > Oh, absolutely. But the question "why are people not running full
>>> > nodes?" has to do with the current implementation, not abstract
>>> > capabilities of a future version of the bitcoind code base.
>>>
>>> The distinction is very important because it's a matter of things we
>>> can and should fix vs things that cannot be fixed except by changing
>>> goals/incentives! Opposite approaches to handling them.
>>>
>>> When I read "resource requirements of a full node are moving beyond" I
>>> didn't extract from that that "there are implementation issues that
>>> need to be improved to make it work better for low resource users" due
>>> to the word "requirements".
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Put Bad Developers to Shame
>>> Dominate Development with Jenkins Continuous Integration
>>> Continuously Automate Build, Test & Deployment
>>> Start a new project now. Try Jenkins in the cloud.
>>> http://p.sf.net/sfu/13600_Cloudbees
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-***@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

[Justus Ranvier]

On 04/07/2014 05:16 PM, Gregory Maxwell wrote:
> When I read "resource requirements of a full node are moving
> beyond" I didn't extract from that that "there are implementation
> issues that need to be improved to make it work better for low
> resource users" due to the word "requirements".

In order to prevent future confusion: whenever I talk about
requirements (or generally use the present tense) , I'm talking about
reality as it currently exists.

If I ever decide to talk about hypothetical future requirements in
some imaginary world of Platonic forms, as opposed to the requirements
imposed by the software that's actually available for casual users to
download today, I'll mention that specifically.

- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

[Mark Friedenbach]

On 04/07/2014 09:57 AM, Gregory Maxwell wrote:
> That is an implementation issue— mostly one that arises as an indirect
> consequence of not having headers first and the parallel fetch, not a
> requirements issue.

Oh, absolutely. But the question "why are people not running full
nodes?" has to do with the current implementation, not abstract
capabilities of a future version of the bitcoind code base.

[Chris Williams]

I’m afraid this is a highly simplistic view of the costs of running a full node.

My node consumes fantastic amounts of data traffic, which is a real cost.

In the 30 days ending Apri 6, my node:

* Received 36.8 gb of data
* Sent 456.5 gb data

At my geographic service location (Singapore), this cost about $90 last month for bandwidth alone. It would be slightly cheaper if I was hosted in the US of course.

But anyone can understand that moving a half-terrabyte of data around in a month will not be cheap.


On Apr 7, 2014, at 8:53 AM, Gregory Maxwell <***@gmail.com> wrote:

> On Mon, Apr 7, 2014 at 8:45 AM, Justus Ranvier <***@gmail.com> wrote:
>> 1. The resource requirements of a full node are moving beyond the
>> capabilities of casual users. This isn't inherently a problem - after
>> all most people don't grow their own food, tailor their own clothes, or
>> keep blacksmith tools handy in to forge their own horseshoes either.
>
> Right now running a full node consumes about $1 in disk space
> non-reoccurring and costs a couple cents in power per month.
>
> This isn't to say things are all ducky. But if you're going to say the
> resource requirements are beyond the capabilities of casual users I'm
> afraid I'm going to have to say: citation needed.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Mike Hearn]

>
> * Sent 456.5 gb data
>
> At my geographic service location (Singapore), this cost about $90 last
> month for bandwidth alone.


One of the reasons I initiated the (now stalled) PayFile project was in
anticipation of this problem:

https://github.com/mikehearn/PayFile
http://www.youtube.com/watch?v=r0BXnWlnIi4&feature=youtu.be

At some point if you want to actually download and validate the full block
chain from scratch, you will have to start paying for it I'm sure.

In the meantime:

1. Getting headers-first implemented and rolled out everywhere would
reduce the amount of redundant downloading and hopefully reduce transmit
traffic network-wide.
2. Implementing chain pruning would allow people to control upload
bandwidth consumption by reducing the amount of disk storage they allow.

[Tamas Blummer]

Headers first loading allows the node to run SPV from the very first minutes and it can converge to full node by time.
This is BTW how newest versions of BOP can work.

Pruning however disqualifies the node as a source for bootstrapping an other full node.
BTW, did we already agree on the service bits for an archive node?


Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 20:23, Mike Hearn <***@plan99.net> wrote:

> * Sent 456.5 gb data
>
> At my geographic service location (Singapore), this cost about $90 last month for bandwidth alone.
>
> One of the reasons I initiated the (now stalled) PayFile project was in anticipation of this problem:
>
> https://github.com/mikehearn/PayFile
> http://www.youtube.com/watch?v=r0BXnWlnIi4&feature=youtu.be
>
> At some point if you want to actually download and validate the full block chain from scratch, you will have to start paying for it I'm sure.
>
> In the meantime:
> Getting headers-first implemented and rolled out everywhere would reduce the amount of redundant downloading and hopefully reduce transmit traffic network-wide.
> Implementing chain pruning would allow people to control upload bandwidth consumption by reducing the amount of disk storage they allow.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Gregory Maxwell]

On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <***@bitsofproof.com> wrote:
> BTW, did we already agree on the service bits for an archive node?

I'm still very concerned that a binary archive bit will cause extreme
load hot-spotting and the kind of binary "Use lots of resources YES or
NO" I think we're currently suffering some from, but at that point
enshrined in the protocol.

It would be much better to extend the addr messages so that nodes can
indicate a range or two of blocks that they're serving, so that all
nodes can contribute fractionally according to their means. E.g. if
you want to offer up 8 GB of distributed storage and contribute to the
availability of the blockchain, without having to swollow the whole
20, 30, 40 ... gigabyte pill.

Already we need that kind of distributed storage for the most recent
blocks to prevent extreme bandwidth load on archives, so extending it
to arbitrary ranges is only more complicated because there is
currently no room to signal it.

[Tamas Blummer]

Once a single transaction in pruned in a block, the block is no longer eligible to be served to other nodes.
Which transactions are pruned can be rather custom e.g. even depending on the wallet(s) of the node,
therefore I guess it is more handy to return some bitmap of pruned/full blocks than ranges.

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 20:49, Gregory Maxwell <***@gmail.com> wrote:

> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <***@bitsofproof.com> wrote:
>> BTW, did we already agree on the service bits for an archive node?
>
> I'm still very concerned that a binary archive bit will cause extreme
> load hot-spotting and the kind of binary "Use lots of resources YES or
> NO" I think we're currently suffering some from, but at that point
> enshrined in the protocol.
>
> It would be much better to extend the addr messages so that nodes can
> indicate a range or two of blocks that they're serving, so that all
> nodes can contribute fractionally according to their means. E.g. if
> you want to offer up 8 GB of distributed storage and contribute to the
> availability of the blockchain, without having to swollow the whole
> 20, 30, 40 ... gigabyte pill.
>
> Already we need that kind of distributed storage for the most recent
> blocks to prevent extreme bandwidth load on archives, so extending it
> to arbitrary ranges is only more complicated because there is
> currently no room to signal it.
>

[Gregory Maxwell]

On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer <***@bitsofproof.com> wrote:
> Once a single transaction in pruned in a block, the block is no longer
> eligible to be served to other nodes.
> Which transactions are pruned can be rather custom e.g. even depending on
> the wallet(s) of the node,
> therefore I guess it is more handy to return some bitmap of pruned/full
> blocks than ranges.

This isn't at all how pruning works in Bitcoin-QT (nor is it how I
expect pruning to work for any mature implementation). Pruning can
work happily on a whole block at a time basis regardless if all the
transactions in it are spent or not.

[Tamas Blummer]

Maybe it is not a question of the maturity of the implementation but that of the person making presumptions of it.

I consider a fully pruned blockchain being equivalent to the UTXO. Block that hold no
more unspent transaction are reduced to a header. There is however no harm if more retained.

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 21:02, Gregory Maxwell <***@gmail.com> wrote:

> On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer <***@bitsofproof.com> wrote:
>> Once a single transaction in pruned in a block, the block is no longer
>> eligible to be served to other nodes.
>> Which transactions are pruned can be rather custom e.g. even depending on
>> the wallet(s) of the node,
>> therefore I guess it is more handy to return some bitmap of pruned/full
>> blocks than ranges.
>
> This isn't at all how pruning works in Bitcoin-QT (nor is it how I
> expect pruning to work for any mature implementation). Pruning can
> work happily on a whole block at a time basis regardless if all the
> transactions in it are spent or not.
>

[Gregory Maxwell]

On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer <***@bitsofproof.com> wrote:
> therefore I guess it is more handy to return some bitmap of pruned/full
> blocks than ranges.

A bitmap also means high overhead and— if it's used to advertise
non-contiguous blocks— poor locality, since blocks are fetched
sequentially.

[Tier Nolan]

On Mon, Apr 7, 2014 at 8:03 PM, Gregory Maxwell <***@gmail.com> wrote:

> A bitmap also means high overhead and-- if it's used to advertise
> non-contiguous blocks-- poor locality, since blocks are fetched
> sequentially.
>

A range seems like a great compromise. Putting it in the address is also a
pretty cool.

If light nodes selected a random contiguous 1GB of the block-chain, then
they could handle most of the download overhead, rather than the full nodes.

Another way to do it would be to have something like a routing table. If a
node is queried for a block, it can reply with the IP of a node with that
block instead of sending the block.

One problem is that it means that light nodes have to accept incoming
connections. Otherwise, it would have to be routed through the network.

[Tamas Blummer]

Once headers are loaded first there is no reason for sequential loading.

Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous.

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 21:03, Gregory Maxwell <***@gmail.com> wrote:

> On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer <***@bitsofproof.com> wrote:
>> therefore I guess it is more handy to return some bitmap of pruned/full
>> blocks than ranges.
>
> A bitmap also means high overhead and— if it's used to advertise
> non-contiguous blocks— poor locality, since blocks are fetched
> sequentially.
>

[Mark Friedenbach]

On 04/07/2014 12:20 PM, Tamas Blummer wrote:
> Validation has to be sequantial, but that step can be deferred until the
> blocks before a point are loaded and continous.

And how do you find those blocks?

I have a suggestion: have nodes advertise which range of full blocks
they possess, then you can perform synchronization from the adversed ranges!

[Tamas Blummer]

You have the trunk defined by the headers. Once a range from genesis to block n is fully downloaded,
you may validate upto block n. Furthermore after validation you can prune transactions spent until block n.

You would approach the highest block with validation and stop pruning say 100 blocks before it, to leave room for reorgs.

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 21:13, Mark Friedenbach <***@monetize.io> wrote:

>
>
> On 04/07/2014 12:20 PM, Tamas Blummer wrote:
>> Validation has to be sequantial, but that step can be deferred until the
>> blocks before a point are loaded and continous.
>
> And how do you find those blocks?
>
> I have a suggestion: have nodes advertise which range of full blocks
> they possess, then you can perform synchronization from the adversed ranges!
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[Ricardo Filipe]

Or have blocks distributed through pruned nodes as a DHT.

2014-04-07 20:13 GMT+01:00 Mark Friedenbach <***@monetize.io>:
>
>
> On 04/07/2014 12:20 PM, Tamas Blummer wrote:
>> Validation has to be sequantial, but that step can be deferred until the
>> blocks before a point are loaded and continous.
>
> And how do you find those blocks?
>
> I have a suggestion: have nodes advertise which range of full blocks
> they possess, then you can perform synchronization from the adversed ranges!
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Paul Lyon]

I hope I'm not thread-jacking here, apologies if so, but that's the approach I've taken with the node I'm working on.
Headers can be downloaded and stored in any order, it'll make sense of what the winning chain is. Blocks don't need to be downloaded in any particular order and they don't need to be saved to disk, the UTXO is fully self-contained. That way the concern of storing blocks for seeding (or not) is wholly separated from syncing the UTXO. This allows me to do the initial blockchain sync in ~6 hours when I use my SSD. I only need enough disk space to store the UTXO, and then whatever amount of block data the user would want to store for the health of the network.
This project is a bitcoin learning exercise for me, so I can only hope I don't have any critical design flaws in there. :)

From: ***@bitsofproof.com
Date: Mon, 7 Apr 2014 21:20:31 +0200
To: ***@gmail.com
CC: bitcoin-***@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Why are we bleeding nodes?


Once headers are loaded first there is no reason for sequential loading.
Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous.
Tamas Blummerhttp://bitsofproof.com


On 07.04.2014, at 21:03, Gregory Maxwell <***@gmail.com> wrote:On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer <***@bitsofproof.com> wrote:
therefore I guess it is more handy to return some bitmap of pruned/full
blocks than ranges.

A bitmap also means high overhead and— if it's used to advertise
non-contiguous blocks— poor locality, since blocks are fetched
sequentially.

[Tamas Blummer]

You have to load headers sequantially to be able to connect them and determine the longest chain.

Blocks can be loaded in random order once you have their order given by the headers.
Computing the UTXO however will force you to at least temporarily store the blocks unless you have plenty of RAM.

Regards,

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 21:30, Paul Lyon <***@hotmail.ca> wrote:

> I hope I'm not thread-jacking here, apologies if so, but that's the approach I've taken with the node I'm working on.
>
> Headers can be downloaded and stored in any order, it'll make sense of what the winning chain is. Blocks don't need to be downloaded in any particular order and they don't need to be saved to disk, the UTXO is fully self-contained. That way the concern of storing blocks for seeding (or not) is wholly separated from syncing the UTXO. This allows me to do the initial blockchain sync in ~6 hours when I use my SSD. I only need enough disk space to store the UTXO, and then whatever amount of block data the user would want to store for the health of the network.
>
> This project is a bitcoin learning exercise for me, so I can only hope I don't have any critical design flaws in there. :)
>
> From: ***@bitsofproof.com
> Date: Mon, 7 Apr 2014 21:20:31 +0200
> To: ***@gmail.com
> CC: bitcoin-***@lists.sourceforge.net
> Subject: Re: [Bitcoin-development] Why are we bleeding nodes?
>
>
> Once headers are loaded first there is no reason for sequential loading.
>
> Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous.
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 07.04.2014, at 21:03, Gregory Maxwell <***@gmail.com> wrote:
>
>> On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer <***@bitsofproof.com> wrote:
>>> therefore I guess it is more handy to return some bitmap of pruned/full
>>> blocks than ranges.
>>
>> A bitmap also means high overhead and— if it's used to advertise
>> non-contiguous blocks— poor locality, since blocks are fetched
>> sequentially.
>>
>
>
> ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________ Bitcoin-development mailing list Bitcoin-***@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Tier Nolan]

On Mon, Apr 7, 2014 at 8:50 PM, Tamas Blummer <***@bitsofproof.com> wrote:

> You have to load headers sequantially to be able to connect them and
> determine the longest chain.
>

The isn't strictly true. If you are connected to a some honest nodes, then
you could download portions of the chain and then connect the various
sub-chains together.

The protocol doesn't support it though. There is no system to ask for
block headers for the main chain block with a given height,

Finding one high bandwidth peer to download the entire header chain
sequentially is pretty much forced. The client can switch if there is a
timeout.

Other peers could be used to parallel download the block chain while the
main chain is downloading. Even if the header download stalled, it
wouldn't be that big a deal.

> Blocks can be loaded in random order once you have their order given by
the headers.
> Computing the UTXO however will force you to at least temporarily store
the blocks unless you have plenty of RAM.

You only need to store the UTXO set, rather than the entire block chain.

It is possible to generate the UTXO set without doing any signature
verification.

A lightweight node could just verify the UTXO set and then do random
signature verifications.

The keeps disk space and CPU reasonably low. If an illegal transaction is
added to be a block, then proof could be provided for the bad transaction.

The only slightly difficult thing is confirming inflation. That can be
checked on a block by block basis when downloading the entire block chain.

> Regards,
> Tamas Blummer
> http://bitsofproof.com <http://bitsofproof.com>

On 07.04.2014, at 21:30, Paul Lyon <***@hotmail.ca> wrote:

I hope I'm not thread-jacking here, apologies if so, but that's the
approach I've taken with the node I'm working on.

Headers can be downloaded and stored in any order, it'll make sense of what
the winning chain is. Blocks don't need to be downloaded in any particular
order and they don't need to be saved to disk, the UTXO is fully
self-contained. That way the concern of storing blocks for seeding (or not)
is wholly separated from syncing the UTXO. This allows me to do the initial
blockchain sync in ~6 hours when I use my SSD. I only need enough disk
space to store the UTXO, and then whatever amount of block data the user
would want to store for the health of the network.

This project is a bitcoin learning exercise for me, so I can only hope I
don't have any critical design flaws in there. :)

------------------------------
From: ***@bitsofproof.com
Date: Mon, 7 Apr 2014 21:20:31 +0200
To: ***@gmail.com
CC: bitcoin-***@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Why are we bleeding nodes?


Once headers are loaded first there is no reason for sequential loading.

Validation has to be sequantial, but that step can be deferred until the
blocks before a point are loaded and continous.

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 21:03, Gregory Maxwell <***@gmail.com> wrote:

On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer <***@bitsofproof.com>
wrote:

therefore I guess it is more handy to return some bitmap of pruned/full
blocks than ranges.


A bitmap also means high overhead and-- if it's used to advertise
non-contiguous blocks-- poor locality, since blocks are fetched
sequentially.



------------------------------------------------------------------------------
Put Bad Developers to Shame Dominate Development with Jenkins Continuous
Integration Continuously Automate Build, Test & Deployment Start a new
project now. Try Jenkins in the cloud.http://p.sf.net/sfu/13600_Cloudbees

_______________________________________________ Bitcoin-development mailing
list Bitcoin-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development



>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[Gregory Maxwell]

On Mon, Apr 7, 2014 at 2:48 PM, Tier Nolan <***@gmail.com> wrote:
>> Blocks can be loaded in random order once you have their order given by
>> the headers.
>> Computing the UTXO however will force you to at least temporarily store
>> the blocks unless you have plenty of RAM.
> You only need to store the UTXO set, rather than the entire block chain.

The comment was specifically in the context of an out of order fetch.
Verification must be in order. If you have fetched blocks out of order
you must preserve them at least long enough to reorder them. Thats
all.

[Mark Friedenbach]

On 04/07/2014 12:00 PM, Tamas Blummer wrote:
> Once a single transaction in pruned in a block, the block is no longer
> eligible to be served to other nodes.
> Which transactions are pruned can be rather custom e.g. even depending
> on the wallet(s) of the node,
> therefore I guess it is more handy to return some bitmap of pruned/full
> blocks than ranges.

The point is that the node has decided not to prune transactions from
that block, so that it is capable of returning full blocks within that
range.

[Jeff Garzik]

Being Mr. Torrent, I've held open the "80% serious" suggestion to
simply refuse to serve blocks older than X (3 months?).

That forces download by other means (presumably torrent).

I do not feel it is productive for any nodes on the network to waste
time/bandwidth/etc. serving static, ancient data. There remain, of
course, issues of older nodes and "getting the word out" that prevents
this switch from being flipped on tomorrow.



On Mon, Apr 7, 2014 at 2:49 PM, Gregory Maxwell <***@gmail.com> wrote:
> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <***@bitsofproof.com> wrote:
>> BTW, did we already agree on the service bits for an archive node?
>
> I'm still very concerned that a binary archive bit will cause extreme
> load hot-spotting and the kind of binary "Use lots of resources YES or
> NO" I think we're currently suffering some from, but at that point
> enshrined in the protocol.
>
> It would be much better to extend the addr messages so that nodes can
> indicate a range or two of blocks that they're serving, so that all
> nodes can contribute fractionally according to their means. E.g. if
> you want to offer up 8 GB of distributed storage and contribute to the
> availability of the blockchain, without having to swollow the whole
> 20, 30, 40 ... gigabyte pill.
>
> Already we need that kind of distributed storage for the most recent
> blocks to prevent extreme bandwidth load on archives, so extending it
> to arbitrary ranges is only more complicated because there is
> currently no room to signal it.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@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/

[Jean-Paul Kogelman]

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 compressed, which would get you about 50% savings.

Also, maybe adding a layer that groups block headers into a single hash (say, 2016 headers), and then being able to fetch those (possibly compressed) header 'blocks' from multiple sources in parallel. And fanning out block fetches even further, favoring fast nodes.

Just thinking out loud.

jp

> On Apr 7, 2014, at 8:44 PM, Jeff Garzik <***@bitpay.com> wrote:
>
> Being Mr. Torrent, I've held open the "80% serious" suggestion to
> simply refuse to serve blocks older than X (3 months?).
>
> That forces download by other means (presumably torrent).
>
> I do not feel it is productive for any nodes on the network to waste
> time/bandwidth/etc. serving static, ancient data. There remain, of
> course, issues of older nodes and "getting the word out" that prevents
> this switch from being flipped on tomorrow.
>
>
>
>> On Mon, Apr 7, 2014 at 2:49 PM, Gregory Maxwell <***@gmail.com> wrote:
>>> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <***@bitsofproof.com> wrote:
>>> BTW, did we already agree on the service bits for an archive node?
>>
>> I'm still very concerned that a binary archive bit will cause extreme
>> load hot-spotting and the kind of binary "Use lots of resources YES or
>> NO" I think we're currently suffering some from, but at that point
>> enshrined in the protocol.
>>
>> It would be much better to extend the addr messages so that nodes can
>> indicate a range or two of blocks that they're serving, so that all
>> nodes can contribute fractionally according to their means. E.g. if
>> you want to offer up 8 GB of distributed storage and contribute to the
>> availability of the blockchain, without having to swollow the whole
>> 20, 30, 40 ... gigabyte pill.
>>
>> Already we need that kind of distributed storage for the most recent
>> blocks to prevent extreme bandwidth load on archives, so extending it
>> to arbitrary ranges is only more complicated because there is
>> currently no room to signal it.
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-***@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/
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Tamas Blummer]

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 mempool transaction validation
against UTXO and use ‘reference’ implementations as border router. I think that this setup will be common for enterprises
and hence push for a stripped down ‘reference’ border router without wallet, payment protocol, GUI, RPC calls here.

That border router could also serve as archive node evtl. also offering blocks at bulk e.g. through http.
Enterprises that run a multi tiered environment have the bandwith to serve as archives.

Tamas Blummer
http://bitsofproof.com

On 08.04.2014, at 05:44, Jeff Garzik <***@bitpay.com> wrote:

> Being Mr. Torrent, I've held open the "80% serious" suggestion to
> simply refuse to serve blocks older than X (3 months?).
>
> That forces download by other means (presumably torrent).
>
> I do not feel it is productive for any nodes on the network to waste
> time/bandwidth/etc. serving static, ancient data. There remain, of
> course, issues of older nodes and "getting the word out" that prevents
> this switch from being flipped on tomorrow.
>
>
>
> On Mon, Apr 7, 2014 at 2:49 PM, Gregory Maxwell <***@gmail.com> wrote:
>> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <***@bitsofproof.com> wrote:
>>> BTW, did we already agree on the service bits for an archive node?
>>
>> I'm still very concerned that a binary archive bit will cause extreme
>> load hot-spotting and the kind of binary "Use lots of resources YES or
>> NO" I think we're currently suffering some from, but at that point
>> enshrined in the protocol.
>>
>> It would be much better to extend the addr messages so that nodes can
>> indicate a range or two of blocks that they're serving, so that all
>> nodes can contribute fractionally according to their means. E.g. if
>> you want to offer up 8 GB of distributed storage and contribute to the
>> availability of the blockchain, without having to swollow the whole
>> 20, 30, 40 ... gigabyte pill.
>>
>> Already we need that kind of distributed storage for the most recent
>> blocks to prevent extreme bandwidth load on archives, so extending it
>> to arbitrary ranges is only more complicated because there is
>> currently no room to signal it.
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-***@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/
>

[Andrew LeCody]

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 12:39 PM, Chris Williams <***@icloudtools.net>wrote:

> I’m afraid this is a highly simplistic view of the costs of running a full
> node.
>
> My node consumes fantastic amounts of data traffic, which is a real cost.
>
> In the 30 days ending Apri 6, my node:
>
> * Received 36.8 gb of data
> * Sent 456.5 gb data
>
> At my geographic service location (Singapore), this cost about $90 last
> month for bandwidth alone. It would be slightly cheaper if I was hosted in
> the US of course.
>
> But anyone can understand that moving a half-terrabyte of data around in a
> month will not be cheap.
>
>
> On Apr 7, 2014, at 8:53 AM, Gregory Maxwell <***@gmail.com> wrote:
>
> > On Mon, Apr 7, 2014 at 8:45 AM, Justus Ranvier <***@gmail.com>
> wrote:
> >> 1. The resource requirements of a full node are moving beyond the
> >> capabilities of casual users. This isn't inherently a problem - after
> >> all most people don't grow their own food, tailor their own clothes, or
> >> keep blacksmith tools handy in to forge their own horseshoes either.
> >
> > Right now running a full node consumes about $1 in disk space
> > non-reoccurring and costs a couple cents in power per month.
> >
> > This isn't to say things are all ducky. But if you're going to say the
> > resource requirements are beyond the capabilities of casual users I'm
> > afraid I'm going to have to say: citation needed.
> >
> >
> ------------------------------------------------------------------------------
> > Put Bad Developers to Shame
> > Dominate Development with Jenkins Continuous Integration
> > Continuously Automate Build, Test & Deployment
> > Start a new project now. Try Jenkins in the cloud.
> > http://p.sf.net/sfu/13600_Cloudbees_APR
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[Drak]

For what it's worth, the number of nodes rose dramatically during the China
bullrun (I recall 45k in China alone) and dropped as dramatically as the
price after the first PBOC announcement designed to cool down bitcoin
trading in China.


On 7 April 2014 12:34, Mike Hearn <***@plan99.net> wrote:

> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500
> and still falling:
>
> http://getaddr.bitnodes.io/dashboard/chart/?days=60
>
> I know all the reasons why people *might* stop running a node (uses too
> much disk space, bandwidth, lost interest etc). But does anyone have any
> idea how we might get more insight into what's really going on? It'd be
> convenient if the subVer contained the operating system, as then we could
> tell if the bleed was mostly from desktops/laptops (Windows/Mac), which
> would be expected, or from virtual servers (Linux), which would be more
> concerning.
>
> When you set up a Tor node, you can add your email address to the config
> file and the Tor project sends you emails from time to time about things
> you should know about. If we did the same, we could have a little exit
> survey: if your node disappears for long enough, we could email the
> operator and ask why they stopped.
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[b***@gmx.com]

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div><span style="font-family: Verdana, sans-serif, Arial, &#39;Trebuchet MS&#39;; font-size: 13px; line-height: 1.6em;">Recently China has updated its firewall blocking bitcoin sites and pools. Whether this is simple blacklist or more&nbsp;</span><span style="font-family: Verdana, sans-serif, Arial, &#39;Trebuchet MS&#39;; font-size: 13px; line-height: 1.6em;">sophisticated</span><span style="font-family: Verdana, sans-serif, Arial, &#39;Trebuchet MS&#39;; font-size: 13px; line-height: 1.6em;">&nbsp;packet targeting is uncertain, however this update did spefically target VPN handshakes.</span></div>

<div>&nbsp;</div>

<div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Sent:</b>&nbsp;Monday, April 07, 2014 at 1:07 PM<br/>
<b>From:</b>&nbsp;Drak &lt;***@zikula.org&gt;<br/>
<b>To:</b>&nbsp;&quot;Mike Hearn&quot; &lt;***@plan99.net&gt;<br/>
<b>Cc:</b>&nbsp;&quot;Bitcoin Dev&quot; &lt;bitcoin-***@lists.sourceforge.net&gt;<br/>
<b>Subject:</b>&nbsp;Re: [Bitcoin-development] Why are we bleeding nodes?</div>

<div name="quoted-content">
<div>For what it&#39;s worth, the number of nodes rose dramatically during the China bullrun (I recall 45k in China alone) and dropped as dramatically as the price after the first PBOC announcement designed to cool down bitcoin trading in China.</div>

<div class="gmail_extra">&nbsp;
<div class="gmail_quote">On 7 April 2014 12:34, Mike Hearn <span>&lt;<a href="***@plan99.net" target="_parent">***@plan99.net</a>&gt;</span> wrote:

<blockquote class="gmail_quote" style="margin: 0 0 0 0.8ex;border-left: 1.0px rgb(204,204,204) solid;padding-left: 1.0ex;">
<div>At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and still falling:
<div>&nbsp;</div>

<div>&nbsp; &nbsp;<a href="http://getaddr.bitnodes.io/dashboard/chart/?days=60" target="_blank">http://getaddr.bitnodes.io/dashboard/chart/?days=60</a></div>

<div>&nbsp;</div>

<div>I know all the reasons why people <i>might</i>&nbsp;stop running a node (uses too much disk space, bandwidth, lost interest etc). But does anyone have any idea how we might get more insight into what&#39;s really going on? It&#39;d be convenient if the subVer contained the operating system, as then we could tell if the bleed was mostly from desktops/laptops (Windows/Mac), which would be expected, or from virtual servers (Linux), which would be more concerning.</div>

<div>&nbsp;</div>

<div>When you set up a Tor node, you can add your email address to the config file and the Tor project sends you emails from time to time about things you should know about. If we did the same, we could have a little exit survey: if your node disappears for long enough, we could email the operator and ask why they stopped.</div>
</div>
<br/>
------------------------------------------------------------------------------<br/>
Put Bad Developers to Shame<br/>
Dominate Development with Jenkins Continuous Integration<br/>
Continuously Automate Build, Test &amp; Deployment<br/>
Start a new project now. Try Jenkins in the cloud.<br/>
<a href="http://p.sf.net/sfu/13600_Cloudbees_APR" target="_blank">http://p.sf.net/sfu/13600_Cloudbees_APR</a><br/>
_______________________________________________<br/>
Bitcoin-development mailing list<br/>
<a href="Bitcoin-***@lists.sourceforge.net" target="_parent">Bitcoin-***@lists.sourceforge.net</a><br/>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br/>
&nbsp;</blockquote>
</div>
</div>
------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test &amp; Deployment Start a new project now. Try Jenkins in the cloud. <a href="http://p.sf.net/sfu/13600_Cloudbees_______________________________________________" target="_blank">http://p.sf.net/sfu/13600_Cloudbees_______________________________________________</a> Bitcoin-development mailing list Bitcoin-***@lists.sourceforge.net <a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a></div>
</div>
</div>
</div>

<div>&nbsp;</div>

<div class="signature">&nbsp;</div></div></body></html>

[Mike Hearn]

Yeah I'm expecting port 8333 to go away in China at some point. Actually I
was expecting that years ago and was kind of surprised that the suppression
was being done via banks. Guess the GFW operators were just slow to catch
up.
On 20 May 2014 10:16, <***@gmx.com> wrote:

> Recently China has updated its firewall blocking bitcoin sites and pools.
> Whether this is simple blacklist or more sophisticated packet targeting
> is uncertain, however this update did spefically target VPN handshakes.
>
> *Sent:* Monday, April 07, 2014 at 1:07 PM
> *From:* Drak <***@zikula.org>
> *To:* "Mike Hearn" <***@plan99.net>
> *Cc:* "Bitcoin Dev" <bitcoin-***@lists.sourceforge.net>
> *Subject:* Re: [Bitcoin-development] Why are we bleeding nodes?
> For what it's worth, the number of nodes rose dramatically during the
> China bullrun (I recall 45k in China alone) and dropped as dramatically as
> the price after the first PBOC announcement designed to cool down bitcoin
> trading in China.
>
> On 7 April 2014 12:34, Mike Hearn <***@plan99.net> wrote:
>>
>> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500
>> and still falling:
>>
>> http://getaddr.bitnodes.io/dashboard/chart/?days=60
>>
>> I know all the reasons why people *might* stop running a node (uses too
>> much disk space, bandwidth, lost interest etc). But does anyone have any
>> idea how we might get more insight into what's really going on? It'd be
>> convenient if the subVer contained the operating system, as then we could
>> tell if the bleed was mostly from desktops/laptops (Windows/Mac), which
>> would be expected, or from virtual servers (Linux), which would be more
>> concerning.
>>
>> When you set up a Tor node, you can add your email address to the config
>> file and the Tor project sends you emails from time to time about things
>> you should know about. If we did the same, we could have a little exit
>> survey: if your node disappears for long enough, we could email the
>> operator and ask why they stopped.
>>
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees_APR
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame Dominate Development with Jenkins Continuous
> Integration Continuously Automate Build, Test & Deployment Start a new
> project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_______________________________________________Bitcoin-development mailing list
> Bitcoin-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>

[Eugen Leitl]

On Tue, May 20, 2014 at 10:15:44AM +0200, ***@gmx.com wrote:
> Recently China has updated its firewall blocking bitcoin sites and pools.
> Whether this is simple blacklist or more sophisticated packet targeting is
> uncertain, however this update did spefically target VPN handshakes.

Could a blockchain fork due to network split happen?
 

[Gmail]

Unlikely. I doubt any significant portion of miners in china will continue to mine on a china-specific chain, since it will certainly be outmined by non-Chinese miners, and will be orphaned eventually.

More likely is that mining interests in china will make special arrangements to circumvent the GFwOC.

Users who can't access the worldwide blockchain will notice horrendously slow confirmation times and other side effects.

> On May 20, 2014, at 10:37, Eugen Leitl <***@leitl.org>
>
> Could a blockchain fork due to network split happen?
>

[Andy Alness]

Has there ever been serious discussion on extending the protocol to
support UDP transport? That would allow for NAT traversal and for many
more people to run effective nodes. I'm also curious if it could be
made improve block propagation time.

On Tue, May 20, 2014 at 7:52 AM, Gmail <***@gmail.com> wrote:
> Unlikely. I doubt any significant portion of miners in china will continue to mine on a china-specific chain, since it will certainly be outmined by non-Chinese miners, and will be orphaned eventually.
>
> More likely is that mining interests in china will make special arrangements to circumvent the GFwOC.
>
> Users who can't access the worldwide blockchain will notice horrendously slow confirmation times and other side effects.
>
>> On May 20, 2014, at 10:37, Eugen Leitl <***@leitl.org>
>>
>> Could a blockchain fork due to network split 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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



--
Andy Alness
Software Engineer
Coinbase
San Francisco, CA

[Jeff Garzik]

Yes, i spec'd out the UDP traversal of the P2P protocol. It seems
reasonable especially for "inv" messages.

On Tue, May 20, 2014 at 2:46 PM, Andy Alness <***@coinbase.com> wrote:
> Has there ever been serious discussion on extending the protocol to
> support UDP transport? That would allow for NAT traversal and for many
> more people to run effective nodes. I'm also curious if it could be
> made improve block propagation time.
>
> On Tue, May 20, 2014 at 7:52 AM, Gmail <***@gmail.com> wrote:
>> Unlikely. I doubt any significant portion of miners in china will continue to mine on a china-specific chain, since it will certainly be outmined by non-Chinese miners, and will be orphaned eventually.
>>
>> More likely is that mining interests in china will make special arrangements to circumvent the GFwOC.
>>
>> Users who can't access the worldwide blockchain will notice horrendously slow confirmation times and other side effects.
>>
>>> On May 20, 2014, at 10:37, Eugen Leitl <***@leitl.org>
>>>
>>> Could a blockchain fork due to network split 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-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> Andy Alness
> Software Engineer
> Coinbase
> San Francisco, CA
>
> ------------------------------------------------------------------------------
> "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-***@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/

[Andy Alness]

Awesome! I'm assuming this is it:
https://bitcointalk.org/index.php?topic=156769.0

It would be interesting (at least to me) to take this a step further
and offer UDP as a full TCP replacement capable of STUN-assisted NAT
traversal and possibly swarmed blockchain syncs. It would require open
TCP nodes to facilitate "connection" establishment. It is obviously a
non-trivial amount of work but would be an interesting experiment.
Maybe BitTorrent's µTP protocol could be leveraged.

On Tue, May 20, 2014 at 12:17 PM, Jeff Garzik <***@bitpay.com> wrote:
> Yes, i spec'd out the UDP traversal of the P2P protocol. It seems
> reasonable especially for "inv" messages.
>
> On Tue, May 20, 2014 at 2:46 PM, Andy Alness <***@coinbase.com> wrote:
>> Has there ever been serious discussion on extending the protocol to
>> support UDP transport? That would allow for NAT traversal and for many
>> more people to run effective nodes. I'm also curious if it could be
>> made improve block propagation time.
>>
>> On Tue, May 20, 2014 at 7:52 AM, Gmail <***@gmail.com> wrote:
>>> Unlikely. I doubt any significant portion of miners in china will continue to mine on a china-specific chain, since it will certainly be outmined by non-Chinese miners, and will be orphaned eventually.
>>>
>>> More likely is that mining interests in china will make special arrangements to circumvent the GFwOC.
>>>
>>> Users who can't access the worldwide blockchain will notice horrendously slow confirmation times and other side effects.
>>>
>>>> On May 20, 2014, at 10:37, Eugen Leitl <***@leitl.org>
>>>>
>>>> Could a blockchain fork due to network split 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-***@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> --
>> Andy Alness
>> Software Engineer
>> Coinbase
>> San Francisco, CA
>>
>> ------------------------------------------------------------------------------
>> "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-***@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/



--
Andy Alness
Software Engineer
Coinbase
San Francisco, CA

[Jeff Garzik]

Indeed -- you must reinvent TCP over UDP, ultimately, to handle blocks
and large TXs.


On Tue, May 20, 2014 at 4:09 PM, Andy Alness <***@coinbase.com> wrote:
> Awesome! I'm assuming this is it:
> https://bitcointalk.org/index.php?topic=156769.0
>
> It would be interesting (at least to me) to take this a step further
> and offer UDP as a full TCP replacement capable of STUN-assisted NAT
> traversal and possibly swarmed blockchain syncs. It would require open
> TCP nodes to facilitate "connection" establishment. It is obviously a
> non-trivial amount of work but would be an interesting experiment.
> Maybe BitTorrent's µTP protocol could be leveraged.
>
> On Tue, May 20, 2014 at 12:17 PM, Jeff Garzik <***@bitpay.com> wrote:
>> Yes, i spec'd out the UDP traversal of the P2P protocol. It seems
>> reasonable especially for "inv" messages.
>>
>> On Tue, May 20, 2014 at 2:46 PM, Andy Alness <***@coinbase.com> wrote:
>>> Has there ever been serious discussion on extending the protocol to
>>> support UDP transport? That would allow for NAT traversal and for many
>>> more people to run effective nodes. I'm also curious if it could be
>>> made improve block propagation time.
>>>
>>> On Tue, May 20, 2014 at 7:52 AM, Gmail <***@gmail.com> wrote:
>>>> Unlikely. I doubt any significant portion of miners in china will continue to mine on a china-specific chain, since it will certainly be outmined by non-Chinese miners, and will be orphaned eventually.
>>>>
>>>> More likely is that mining interests in china will make special arrangements to circumvent the GFwOC.
>>>>
>>>> Users who can't access the worldwide blockchain will notice horrendously slow confirmation times and other side effects.
>>>>
>>>>> On May 20, 2014, at 10:37, Eugen Leitl <***@leitl.org>
>>>>>
>>>>> Could a blockchain fork due to network split 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-***@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>>
>>>
>>> --
>>> Andy Alness
>>> Software Engineer
>>> Coinbase
>>> San Francisco, CA
>>>
>>> ------------------------------------------------------------------------------
>>> "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-***@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/
>
>
>
> --
> Andy Alness
> Software Engineer
> Coinbase
> San Francisco, CA



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

[unknown]

--_3de1e55d-a546-4f49-9371-5ae7e50d08c3_
Content-Type: multipart/alternative;
boundary="_1555FEC0-E1BD-4E67-AEFA-487462CF1D89_"

--_1555FEC0-E1BD-4E67-AEFA-487462CF1D89_
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"

SSBhY3R1YWxseSBhc2sgZm9yIGhlYWRlcnMgZnJvbSBlYWNoIHBlZXIgSeKAmW0gY29ubmVjdGVk
IHRvIGFuZCB0aGVuIGR1bXAgdGhlbSBpbnRvIHRoZSBiYWNrZW5kIHRvIGJlIHNvcnRlZCBvdXQu
LiBpcyB0aGlzIGFidXNpdmUgdG8gdGhlIG5ldHdvcms/IEnigJltIGNvbmNlcm5lZCBhYm91dCB0
aGF0IGFzIEkgd29yayBvbiB0aGlzLCBpdCBvbmx5IGRhd25lZCBvbiBtZSB0aGUgb3RoZXIgbmln
aHQgdGhhdCBJIHJlYWxseSBzaG91bGRu4oCZdCB1c2UgdGhlIHNlZWQgcGVlcnMgZm9yIGRvd25s
b2FkaW5n4oCmDQoNCg0KSSBmaWd1cmVkIHdpdGggdGhlIGhlYWRlcnMgYmVpbmcgc28gdGlueSwg
aXQgd291bGRu4oCZdCBiZSBhIGJ1cmRlbiB0byBhc2sgZm9yIHRoZW0gZnJvbSBlYWNoIHBlZXIu
IEkgd29u4oCZdCBhY3R1YWxseSBlbmQgdXAgZG93bmxvYWRpbmcgdGhlIGZ1bGwgYmxvY2tjaGFp
buKAmXMgd29ydGggb2YgaGVhZGVycyBmcm9tIGV2ZXJ5IHBlZXI7IEnigJltIGNvbnRpbnVhbGx5
IGdldHRpbmcgYW4gdXBkYXRlZCB2aWV3IG9mIHRoZSBjdXJyZW50IHdpbm5pbmcgY2hhaW4gYmVm
b3JlIEkgc2VuZCBvdXQgYWRkaXRpb25hbCBoZWFkZXIgcmVxdWVzdHMgdG8gcGVlcnMuDQoNCg0K
DQoNCg0KDQpGcm9tOiBUaWVyIE5vbGFuDQpTZW50OiDigI5Nb25kYXnigI4sIOKAjkFwcmls4oCO
IOKAjjA34oCOLCDigI4yMDE0IOKAjjbigI464oCONDjigI4g4oCOUE0NClRvOiBiaXRjb2luLWRl
dmVsb3BtZW50QGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KDQoNCg0KDQoNCg0KDQoNCk9uIE1vbiwg
QXByIDcsIDIwMTQgYXQgODo1MCBQTSwgVGFtYXMgQmx1bW1lciA8dGFtYXNAYml0c29mcHJvb2Yu
Y29tPiB3cm90ZToNCg0KDQpZb3UgaGF2ZSB0byBsb2FkIGhlYWRlcnMgc2VxdWFudGlhbGx5IHRv
IGJlIGFibGUgdG8gY29ubmVjdCB0aGVtIGFuZCBkZXRlcm1pbmUgdGhlIGxvbmdlc3QgY2hhaW4u
DQoNCg0KDQoNClRoZSBpc24ndCBzdHJpY3RseSB0cnVlLiAgSWYgeW91IGFyZSBjb25uZWN0ZWQg
dG8gYSBzb21lIGhvbmVzdCBub2RlcywgdGhlbiB5b3UgY291bGQgZG93bmxvYWQgcG9ydGlvbnMg
b2YgdGhlIGNoYWluIGFuZCB0aGVuIGNvbm5lY3QgdGhlIHZhcmlvdXMgc3ViLWNoYWlucyB0b2dl
dGhlci4NCg0KVGhlIHByb3RvY29sIGRvZXNuJ3Qgc3VwcG9ydCBpdCB0aG91Z2guICBUaGVyZSBp
cyBubyBzeXN0ZW0gdG8gYXNrIGZvciBibG9jayBoZWFkZXJzIGZvciB0aGUgbWFpbiBjaGFpbiBi
bG9jayB3aXRoIGEgZ2l2ZW4gaGVpZ2h0LA0KDQoNCkZpbmRpbmcgb25lIGhpZ2ggYmFuZHdpZHRo
IHBlZXIgdG8gZG93bmxvYWQgdGhlIGVudGlyZSBoZWFkZXIgY2hhaW4gc2VxdWVudGlhbGx5IGlz
IHByZXR0eSBtdWNoIGZvcmNlZC4gIFRoZSBjbGllbnQgY2FuIHN3aXRjaCBpZiB0aGVyZSBpcyBh
IHRpbWVvdXQuDQoNCg0KT3RoZXIgcGVlcnMgY291bGQgYmUgdXNlZCB0byBwYXJhbGxlbCBkb3du
bG9hZCB0aGUgYmxvY2sgY2hhaW4gd2hpbGUgdGhlIG1haW4gY2hhaW4gaXMgZG93bmxvYWRpbmcu
ICBFdmVuIGlmIHRoZSBoZWFkZXIgZG93bmxvYWQgc3RhbGxlZCwgaXQgd291bGRuJ3QgYmUgdGhh
dCBiaWcgYSBkZWFsLg0KDQoNCg0KDQoNCg0KPiBCbG9ja3MgY2FuIGJlIGxvYWRlZCBpbiByYW5k
b20gb3JkZXIgb25jZSB5b3UgaGF2ZSB0aGVpciBvcmRlciBnaXZlbiBieSB0aGUgaGVhZGVycy4N
Cj4gQ29tcHV0aW5nIHRoZSBVVFhPIGhvd2V2ZXIgd2lsbCBmb3JjZSB5b3UgdG8gYXQgbGVhc3Qg
dGVtcG9yYXJpbHkgc3RvcmUgdGhlIGJsb2NrcyB1bmxlc3MgeW91IGhhdmUgcGxlbnR5IG9mIFJB
TS4gDQoNCg0KWW91IG9ubHkgbmVlZCB0byBzdG9yZSB0aGUgVVRYTyBzZXQsIHJhdGhlciB0aGFu
IHRoZSBlbnRpcmUgYmxvY2sgY2hhaW4uDQoNCg0KDQpJdCBpcyBwb3NzaWJsZSB0byBnZW5lcmF0
ZSB0aGUgVVRYTyBzZXQgd2l0aG91dCBkb2luZyBhbnkgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbi4N
Cg0KDQoNCkEgbGlnaHR3ZWlnaHQgbm9kZSBjb3VsZCBqdXN0IHZlcmlmeSB0aGUgVVRYTyBzZXQg
YW5kIHRoZW4gZG8gcmFuZG9tIHNpZ25hdHVyZSB2ZXJpZmljYXRpb25zLg0KDQoNCg0KVGhlIGtl
ZXBzIGRpc2sgc3BhY2UgYW5kIENQVSByZWFzb25hYmx5IGxvdy4gIElmIGFuIGlsbGVnYWwgdHJh
bnNhY3Rpb24gaXMgYWRkZWQgdG8gYmUgYSBibG9jaywgdGhlbiBwcm9vZiBjb3VsZCBiZSBwcm92
aWRlZCBmb3IgdGhlIGJhZCB0cmFuc2FjdGlvbi4NCg0KDQoNClRoZSBvbmx5IHNsaWdodGx5IGRp
ZmZpY3VsdCB0aGluZyBpcyBjb25maXJtaW5nIGluZmxhdGlvbi4gIFRoYXQgY2FuIGJlIGNoZWNr
ZWQgb24gYSBibG9jayBieSBibG9jayBiYXNpcyB3aGVuIGRvd25sb2FkaW5nIHRoZSBlbnRpcmUg
YmxvY2sgY2hhaW4uDQoNCg0KDQoNCj4gUmVnYXJkcywNCj4gVGFtYXMgQmx1bW1lcg0KPiBodHRw
Oi8vYml0c29mcHJvb2YuY29tIA0KDQoNCg0KDQpPbiAwNy4wNC4yMDE0LCBhdCAyMTozMCwgUGF1
bCBMeW9uIDxwbWx5b25AaG90bWFpbC5jYT4gd3JvdGU6DQoNCg0KDQoNCg0KSSBob3BlIEknbSBu
b3QgdGhyZWFkLWphY2tpbmcgaGVyZSwgYXBvbG9naWVzIGlmIHNvLCBidXQgdGhhdCdzIHRoZSBh
cHByb2FjaCBJJ3ZlIHRha2VuIHdpdGggdGhlIG5vZGUgSSdtIHdvcmtpbmcgb24uDQoNCg0KDQpI
ZWFkZXJzIGNhbiBiZSBkb3dubG9hZGVkIGFuZCBzdG9yZWQgaW4gYW55IG9yZGVyLCBpdCdsbCBt
YWtlIHNlbnNlIG9mIHdoYXQgdGhlIHdpbm5pbmcgY2hhaW4gaXMuIEJsb2NrcyBkb24ndCBuZWVk
IHRvIGJlIGRvd25sb2FkZWQgaW4gYW55IHBhcnRpY3VsYXIgb3JkZXIgYW5kIHRoZXkgZG9uJ3Qg
bmVlZCB0byBiZSBzYXZlZCB0byBkaXNrLCB0aGUgVVRYTyBpcyBmdWxseSBzZWxmLWNvbnRhaW5l
ZC4gVGhhdCB3YXkgdGhlIGNvbmNlcm4gb2Ygc3RvcmluZyBibG9ja3MgZm9yIHNlZWRpbmcgKG9y
IG5vdCkgaXMgd2hvbGx5IHNlcGFyYXRlZCBmcm9tIHN5bmNpbmcgdGhlIFVUWE8uIFRoaXMgYWxs
b3dzIG1lIHRvIGRvIHRoZSBpbml0aWFsIGJsb2NrY2hhaW4gc3luYyBpbiB+NiBob3VycyB3aGVu
IEkgdXNlIG15IFNTRC4gSSBvbmx5IG5lZWQgZW5vdWdoIGRpc2sgc3BhY2UgdG8gc3RvcmUgdGhl
IFVUWE8sIGFuZCB0aGVuIHdoYXRldmVyIGFtb3VudCBvZiBibG9jayBkYXRhIHRoZSB1c2VyIHdv
dWxkIHdhbnQgdG8gc3RvcmUgZm9yIHRoZSBoZWFsdGggb2YgdGhlIG5ldHdvcmsuDQoNCg0KDQoN
Cg0KVGhpcyBwcm9qZWN0IGlzIGEgYml0Y29pbiBsZWFybmluZyBleGVyY2lzZSBmb3IgbWUsIHNv
IEkgY2FuIG9ubHkgaG9wZSBJIGRvbid0IGhhdmUgYW55IGNyaXRpY2FsIGRlc2lnbiBmbGF3cyBp
biB0aGVyZS4gOikNCg0KDQoNCg0KDQoNCkZyb206IHRhbWFzQGJpdHNvZnByb29mLmNvbQ0KRGF0
ZTogTW9uLCA3IEFwciAyMDE0IDIxOjIwOjMxICswMjAwDQpUbzogZ21heHdlbGxAZ21haWwuY29t
DQpDQzogYml0Y29pbi1kZXZlbG9wbWVudEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNClN1YmplY3Q6
IFJlOiBbQml0Y29pbi1kZXZlbG9wbWVudF0gV2h5IGFyZSB3ZSBibGVlZGluZyBub2Rlcz8NCg0K
DQoNCg0KDQpPbmNlIGhlYWRlcnMgYXJlIGxvYWRlZCBmaXJzdCB0aGVyZSBpcyBubyByZWFzb24g
Zm9yIHNlcXVlbnRpYWwgbG9hZGluZy4gDQoNCg0KDQoNClZhbGlkYXRpb24gaGFzIHRvIGJlIHNl
cXVhbnRpYWwsIGJ1dCB0aGF0IHN0ZXAgY2FuIGJlIGRlZmVycmVkIHVudGlsIHRoZSBibG9ja3Mg
YmVmb3JlIGEgcG9pbnQgYXJlIGxvYWRlZCBhbmQgY29udGlub3VzLg0KDQoNClRhbWFzIEJsdW1t
ZXINCmh0dHA6Ly9iaXRzb2Zwcm9vZi5jb20NCg0KDQoNCk9uIDA3LjA0LjIwMTQsIGF0IDIxOjAz
LCBHcmVnb3J5IE1heHdlbGwgPGdtYXh3ZWxsQGdtYWlsLmNvbT4gd3JvdGU6DQoNCg0KT24gTW9u
LCBBcHIgNywgMjAxNCBhdCAxMjowMCBQTSwgVGFtYXMgQmx1bW1lciA8dGFtYXNAYml0c29mcHJv
b2YuY29tPiB3cm90ZToNCg0KdGhlcmVmb3JlIEkgZ3Vlc3MgaXQgaXMgbW9yZSBoYW5keSB0byBy
ZXR1cm4gc29tZSBiaXRtYXAgb2YgcHJ1bmVkL2Z1bGwNCmJsb2NrcyB0aGFuIHJhbmdlcy4NCg0K
DQpBIGJpdG1hcCBhbHNvIG1lYW5zIGhpZ2ggb3ZlcmhlYWQgYW5k4oCUIGlmIGl0J3MgdXNlZCB0
byBhZHZlcnRpc2UNCm5vbi1jb250aWd1b3VzIGJsb2Nrc+KAlCBwb29yIGxvY2FsaXR5LCBzaW5j
ZSBibG9ja3MgYXJlIGZldGNoZWQNCnNlcXVlbnRpYWxseS4NCg0KDQoNCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLSBQdXQgQmFkIERldmVsb3BlcnMgdG8gU2hhbWUgRG9taW5hdGUgRGV2ZWxvcG1lbnQg
d2l0aCBKZW5raW5zIENvbnRpbnVvdXMgSW50ZWdyYXRpb24gQ29udGludW91c2x5IEF1dG9tYXRl
IEJ1aWxkLCBUZXN0ICYgRGVwbG95bWVudCBTdGFydCBhIG5ldyBwcm9qZWN0IG5vdy4gVHJ5IEpl
bmtpbnMgaW4gdGhlIGNsb3VkLmh0dHA6Ly9wLnNmLm5ldC9zZnUvMTM2MDBfQ2xvdWRiZWVzDQog
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBCaXRjb2lu
LWRldmVsb3BtZW50IG1haWxpbmcgbGlzdCBCaXRjb2luLWRldmVsb3BtZW50QGxpc3RzLnNvdXJj
ZWZvcmdlLm5ldGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2Jp
dGNvaW4tZGV2ZWxvcG1lbnQNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUHV0IEJhZCBE
ZXZlbG9wZXJzIHRvIFNoYW1lDQpEb21pbmF0ZSBEZXZlbG9wbWVudCB3aXRoIEplbmtpbnMgQ29u
dGludW91cyBJbnRlZ3JhdGlvbg0KQ29udGludW91c2x5IEF1dG9tYXRlIEJ1aWxkLCBUZXN0ICYg
RGVwbG95bWVudA0KU3RhcnQgYSBuZXcgcHJvamVjdCBub3cuIFRyeSBKZW5raW5zIGluIHRoZSBj
bG91ZC4NCmh0dHA6Ly9wLnNmLm5ldC9zZnUvMTM2MDBfQ2xvdWRiZWVzDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQml0Y29pbi1kZXZlbG9wbWVudCBt
YWlsaW5nIGxpc3QNCkJpdGNvaW4tZGV2ZWxvcG1lbnRAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpo
dHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9iaXRjb2luLWRldmVs
b3BtZW50

--_1555FEC0-E1BD-4E67-AEFA-487462CF1D89_
Content-Transfer-Encoding: base64
Content-Type: text/html; charset="utf-8"

CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h
aWwgMTcuNS45NjAwLjIwNDEzIj4KPHN0eWxlIGRhdGEtZXh0ZXJuYWxzdHlsZT0idHJ1ZSI+PCEt
LQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy
YWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0b206
MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbCB7Cm1hcmdpbjowaW47Cm1hcmdpbi1ib3R0
b206LjAwMDFwdDsKfQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGxpLk1zb0xpc3RQYXJh
Z3JhcGhDeFNwRmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCAKcC5Nc29MaXN0
UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGRpdi5N
c29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBs
aS5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3Qg
ewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1h
cmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsK
fQotLT48L3N0eWxlPjwvaGVhZD4KPGJvZHkgZGlyPSJsdHIiPgo8ZGl2IGRhdGEtZXh0ZXJuYWxz
dHlsZT0iZmFsc2UiIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDYWxpYnJpJywgJ1Nl
Z29lIFVJJywgJ01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9zb2Z0IEpoZW5n
SGVpIFVJJywgJ01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZic7Zm9udC1zaXplOjEycHQ7Ij48
ZGl2PkkgYWN0dWFsbHkgYXNrIGZvciBoZWFkZXJzIGZyb20gZWFjaCBwZWVyIEnigJltIGNvbm5l
Y3RlZCB0byBhbmQgdGhlbiBkdW1wIHRoZW0gaW50byB0aGUgYmFja2VuZCB0byBiZSBzb3J0ZWQg
b3V0Li4gaXMgdGhpcyBhYnVzaXZlIHRvIHRoZSBuZXR3b3JrPyBJ4oCZbSBjb25jZXJuZWQgYWJv
dXQgdGhhdCBhcyBJIHdvcmsgb24gdGhpcywgaXQgb25seSBkYXduZWQgb24gbWUgdGhlIG90aGVy
IG5pZ2h0IHRoYXQgSSByZWFsbHkgc2hvdWxkbuKAmXQgdXNlIHRoZSBzZWVkIHBlZXJzIGZvciBk
b3dubG9hZGluZ+KApjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBmaWd1cmVkIHdpdGggdGhl
IGhlYWRlcnMgYmVpbmcgc28gdGlueSwgaXQgd291bGRu4oCZdCBiZSBhIGJ1cmRlbiB0byBhc2sg
Zm9yIHRoZW0gZnJvbSBlYWNoIHBlZXIuIEkgd29u4oCZdCBhY3R1YWxseSBlbmQgdXAgZG93bmxv
YWRpbmcgdGhlIGZ1bGwgYmxvY2tjaGFpbuKAmXMgd29ydGggb2YgaGVhZGVycyBmcm9tIGV2ZXJ5
IHBlZXI7IEnigJltIGNvbnRpbnVhbGx5IGdldHRpbmcgYW4gdXBkYXRlZCB2aWV3IG9mIHRoZSBj
dXJyZW50IHdpbm5pbmcgY2hhaW4gYmVmb3JlIEkgc2VuZCBvdXQgYWRkaXRpb25hbCBoZWFkZXIg
cmVxdWVzdHMgdG8gcGVlcnMuPGJyPjwvZGl2PjxkaXYgZGF0YS1zaWduYXR1cmVibG9jaz0idHJ1
ZSI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9InBhZGRpbmctdG9wOiA1cHg7IGJvcmRlci10b3AtY29s
b3I6IHJnYigyMjksIDIyOSwgMjI5KTsgYm9yZGVyLXRvcC13aWR0aDogMXB4OyBib3JkZXItdG9w
LXN0eWxlOiBzb2xpZDsiPjxkaXY+PGZvbnQgZmFjZT0iICdDYWxpYnJpJywgJ1NlZ29lIFVJJywg
J01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9zb2Z0IEpoZW5nSGVpIFVJJywg
J01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZiciIHN0eWxlPSdsaW5lLWhlaWdodDogMTVwdDsg
bGV0dGVyLXNwYWNpbmc6IDAuMDJlbTsgZm9udC1mYW1pbHk6ICJDYWxpYnJpIiwgIlNlZ29lIFVJ
IiwgIk1laXJ5byIsICJNaWNyb3NvZnQgWWFIZWkgVUkiLCAiTWljcm9zb2Z0IEpoZW5nSGVpIFVJ
IiwgIk1hbGd1biBHb3RoaWMiLCAic2Fucy1zZXJpZiI7IGZvbnQtc2l6ZTogMTJwdDsnPjxiPkZy
b206PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzp0aWVyLm5vbGFuQGdtYWlsLmNvbSIgdGFyZ2V0
PSJfcGFyZW50Ij5UaWVyIE5vbGFuPC9hPjxicj48Yj5TZW50OjwvYj4mbmJzcDvigI5Nb25kYXni
gI4sIOKAjkFwcmls4oCOIOKAjjA34oCOLCDigI4yMDE0IOKAjjbigI464oCONDjigI4g4oCOUE08
YnI+PGI+VG86PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpiaXRjb2luLWRldmVsb3BtZW50QGxp
c3RzLnNvdXJjZWZvcmdlLm5ldCIgdGFyZ2V0PSJfcGFyZW50Ij5iaXRjb2luLWRldmVsb3BtZW50
QGxpc3RzLnNvdXJjZWZvcmdlLm5ldDwvYT48L2ZvbnQ+PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9k
aXY+PGRpdiBkaXI9IiI+PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxi
cj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBBcHIgNywgMjAxNCBhdCA4OjUwIFBN
LCBUYW1hcyBCbHVtbWVyIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnRhbWFz
QGJpdHNvZnByb29mLmNvbSIgdGFyZ2V0PSJfcGFyZW50Ij50YW1hc0BiaXRzb2Zwcm9vZi5jb208
L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi
IHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsgYm9y
ZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFw
eDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyI+PGRpdiBzdHlsZT0iLW1zLXdvcmQtd3JhcDog
YnJlYWstd29yZDsiPllvdSBoYXZlIHRvIGxvYWQgaGVhZGVycyBzZXF1YW50aWFsbHkgdG8gYmUg
YWJsZSB0byBjb25uZWN0IHRoZW0gYW5kIGRldGVybWluZSB0aGUgbG9uZ2VzdCBjaGFpbi48L2Rp
dj4KPC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9Ii1tcy13b3JkLXdyYXA6
IGJyZWFrLXdvcmQ7Ij5UaGUgaXNuJ3Qgc3RyaWN0bHkgdHJ1ZS4mbmJzcDsgSWYgeW91IGFyZSBj
b25uZWN0ZWQgdG8gYSBzb21lIGhvbmVzdCBub2RlcywgdGhlbiB5b3UgY291bGQgZG93bmxvYWQg
cG9ydGlvbnMgb2YgdGhlIGNoYWluIGFuZCB0aGVuIGNvbm5lY3QgdGhlIHZhcmlvdXMgc3ViLWNo
YWlucyB0b2dldGhlci48YnI+Cjxicj5UaGUgcHJvdG9jb2wgZG9lc24ndCBzdXBwb3J0IGl0IHRo
b3VnaC4mbmJzcDsgVGhlcmUgaXMgbm8gc3lzdGVtIHRvIGFzayBmb3IgYmxvY2sgaGVhZGVycyBm
b3IgdGhlIG1haW4gY2hhaW4gYmxvY2sgd2l0aCBhIGdpdmVuIGhlaWdodCw8YnI+PGJyPjwvZGl2
PkZpbmRpbmcgb25lIGhpZ2ggYmFuZHdpZHRoIHBlZXIgdG8gZG93bmxvYWQgdGhlIGVudGlyZSBo
ZWFkZXIgY2hhaW4gc2VxdWVudGlhbGx5IGlzIHByZXR0eSBtdWNoIGZvcmNlZC4mbmJzcDsgVGhl
IGNsaWVudCBjYW4gc3dpdGNoIGlmIHRoZXJlIGlzIGEgdGltZW91dC48YnI+Cjxicj48L2Rpdj48
ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T3RoZXIgcGVlcnMgY291bGQgYmUgdXNlZCB0byBwYXJh
bGxlbCBkb3dubG9hZCB0aGUgYmxvY2sgY2hhaW4gd2hpbGUgdGhlIG1haW4gY2hhaW4gaXMgZG93
bmxvYWRpbmcuJm5ic3A7IEV2ZW4gaWYgdGhlIGhlYWRlciBkb3dubG9hZCBzdGFsbGVkLCBpdCB3
b3VsZG4ndCBiZSB0aGF0IGJpZyBhIGRlYWwuPGJyPjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX3F1
b3RlIj4KPGRpdiBzdHlsZT0iLW1zLXdvcmQtd3JhcDogYnJlYWstd29yZDsiPjxicj48ZGl2Pjxk
aXY+Jmd0OyBCbG9ja3MgY2FuIGJlIGxvYWRlZCBpbiByYW5kb20gb3JkZXIgb25jZSB5b3UgaGF2
ZSB0aGVpciBvcmRlciBnaXZlbiBieSB0aGUgaGVhZGVycy48L2Rpdj4mZ3Q7IENvbXB1dGluZyB0
aGUgVVRYTyBob3dldmVyIHdpbGwgZm9yY2UgeW91IHRvIGF0IGxlYXN0IHRlbXBvcmFyaWx5IHN0
b3JlIHRoZSBibG9ja3MgdW5sZXNzIHlvdSBoYXZlIHBsZW50eSBvZiBSQU0uIDxicj4KPGJyPjwv
ZGl2PjxkaXY+WW91IG9ubHkgbmVlZCB0byBzdG9yZSB0aGUgVVRYTyBzZXQsIHJhdGhlciB0aGFu
IHRoZSBlbnRpcmUgYmxvY2sgY2hhaW4uPGJyPjxicj48L2Rpdj48ZGl2Pkl0IGlzIHBvc3NpYmxl
IHRvIGdlbmVyYXRlIHRoZSBVVFhPIHNldCB3aXRob3V0IGRvaW5nIGFueSBzaWduYXR1cmUgdmVy
aWZpY2F0aW9uLjxicj48YnI+PC9kaXY+PGRpdj5BIGxpZ2h0d2VpZ2h0IG5vZGUgY291bGQganVz
dCB2ZXJpZnkgdGhlIFVUWE8gc2V0IGFuZCB0aGVuIGRvIHJhbmRvbSBzaWduYXR1cmUgdmVyaWZp
Y2F0aW9ucy48YnI+Cjxicj48L2Rpdj48ZGl2PlRoZSBrZWVwcyBkaXNrIHNwYWNlIGFuZCBDUFUg
cmVhc29uYWJseSBsb3cuJm5ic3A7IElmIGFuIGlsbGVnYWwgdHJhbnNhY3Rpb24gaXMgYWRkZWQg
dG8gYmUgYSBibG9jaywgdGhlbiBwcm9vZiBjb3VsZCBiZSBwcm92aWRlZCBmb3IgdGhlIGJhZCB0
cmFuc2FjdGlvbi48YnI+PGJyPjwvZGl2PjxkaXY+VGhlIG9ubHkgc2xpZ2h0bHkgZGlmZmljdWx0
IHRoaW5nIGlzIGNvbmZpcm1pbmcgaW5mbGF0aW9uLiZuYnNwOyBUaGF0IGNhbiBiZSBjaGVja2Vk
IG9uIGEgYmxvY2sgYnkgYmxvY2sgYmFzaXMgd2hlbiBkb3dubG9hZGluZyB0aGUgZW50aXJlIGJs
b2NrIGNoYWluLjxicj4KPC9kaXY+PGRpdj48YnIgc3R5bGU9ImZvbnQ6IDEycHgvbm9ybWFsIEhl
bHZldGljYTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1z
cGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyBm
b250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1hbDsiPgo8ZGl2PjxzcGFu
IHN0eWxlPSJmb250OiAxMnB4L25vcm1hbCBIZWx2ZXRpY2E7IHRleHQtdHJhbnNmb3JtOiBub25l
OyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6
IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFj
ZTogbm9ybWFsOyBmb250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1hbDsi
PiZndDsgUmVnYXJkcyw8L3NwYW4+PGJyIHN0eWxlPSJmb250OiAxMnB4L25vcm1hbCBIZWx2ZXRp
Y2E7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgZm9udC1z
aXplLWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNoOiBub3JtYWw7Ij4KPHNwYW4gc3R5bGU9ImZv
bnQ6IDEycHgvbm9ybWFsIEhlbHZldGljYTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5k
ZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyBmbG9h
dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyI+Jmd0OyBUYW1h
cyBCbHVtbWVyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250OiAxMnB4L25vcm1hbCBIZWx2ZXRpY2E7
IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzog
bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgZm9udC1zaXpl
LWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNoOiBub3JtYWw7Ij48YnIgc3R5bGU9ImZvbnQ6IDEy
cHgvbm9ybWFsIEhlbHZldGljYTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAw
cHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFj
ZTogbm9ybWFsOyBmb250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1hbDsi
Pgo8c3BhbiBzdHlsZT0iZm9udDogMTJweC9ub3JtYWwgSGVsdmV0aWNhOyB0ZXh0LXRyYW5zZm9y
bTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1z
cGFjaW5nOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgd2hp
dGUtc3BhY2U6IG5vcm1hbDsgZm9udC1zaXplLWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNoOiBu
b3JtYWw7Ij48YSBocmVmPSJodHRwOi8vYml0c29mcHJvb2YuY29tIiB0YXJnZXQ9Il9wYXJlbnQi
PiZndDsgaHR0cDovL2JpdHNvZnByb29mLmNvbTwvYT48L3NwYW4+Cjwvc3Bhbj48L2Rpdj4KPGJy
PjxkaXY+PGRpdj48ZGl2Pk9uIDA3LjA0LjIwMTQsIGF0IDIxOjMwLCBQYXVsIEx5b24gJmx0Ozxh
IGhyZWY9Im1haWx0bzpwbWx5b25AaG90bWFpbC5jYSIgdGFyZ2V0PSJfcGFyZW50Ij5wbWx5b25A
aG90bWFpbC5jYTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pjxicj48L2Rpdj48YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48ZGl2IHN0eWxlPSJmb250
OiAxMnB0L25vcm1hbCBDYWxpYnJpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6
IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRjaDogbm9ybWFs
OyI+CjxkaXYgZGlyPSJsdHIiPjxkaXY+SSBob3BlIEknbSBub3QgdGhyZWFkLWphY2tpbmcgaGVy
ZSwgYXBvbG9naWVzIGlmIHNvLCBidXQgdGhhdCdzIHRoZSBhcHByb2FjaCBJJ3ZlIHRha2VuIHdp
dGggdGhlIG5vZGUgSSdtIHdvcmtpbmcgb24uPGRpdj48YnI+PC9kaXY+PGRpdj5IZWFkZXJzIGNh
biBiZSBkb3dubG9hZGVkIGFuZCBzdG9yZWQgaW4gYW55IG9yZGVyLCBpdCdsbCBtYWtlIHNlbnNl
IG9mIHdoYXQgdGhlIHdpbm5pbmcgY2hhaW4gaXMuIEJsb2NrcyBkb24ndCBuZWVkIHRvIGJlIGRv
d25sb2FkZWQgaW4gYW55IHBhcnRpY3VsYXIgb3JkZXIgYW5kIHRoZXkgZG9uJ3QgbmVlZCB0byBi
ZSBzYXZlZCB0byBkaXNrLCB0aGUgVVRYTyBpcyBmdWxseSBzZWxmLWNvbnRhaW5lZC4gVGhhdCB3
YXkgdGhlIGNvbmNlcm4gb2Ygc3RvcmluZyBibG9ja3MgZm9yIHNlZWRpbmcgKG9yIG5vdCkgaXMg
d2hvbGx5IHNlcGFyYXRlZCBmcm9tIHN5bmNpbmcgdGhlIFVUWE8uIFRoaXMgYWxsb3dzIG1lIHRv
IGRvIHRoZSBpbml0aWFsIGJsb2NrY2hhaW4gc3luYyBpbiB+NiBob3VycyB3aGVuIEkgdXNlIG15
IFNTRC4gSSBvbmx5IG5lZWQgZW5vdWdoIGRpc2sgc3BhY2UgdG8gc3RvcmUgdGhlIFVUWE8sIGFu
ZCB0aGVuIHdoYXRldmVyIGFtb3VudCBvZiBibG9jayBkYXRhIHRoZSB1c2VyIHdvdWxkIHdhbnQg
dG8gc3RvcmUgZm9yIHRoZSBoZWFsdGggb2YgdGhlIG5ldHdvcmsuPC9kaXY+CjxkaXY+PGJyPjwv
ZGl2PjwvZGl2PjxkaXY+PGRpdj5UaGlzIHByb2plY3QgaXMgYSBiaXRjb2luIGxlYXJuaW5nIGV4
ZXJjaXNlIGZvciBtZSwgc28gSSBjYW4gb25seSBob3BlIEkgZG9uJ3QgaGF2ZSBhbnkgY3JpdGlj
YWwgZGVzaWduIGZsYXdzIGluIHRoZXJlLiA6KTxicj48YnI+PC9kaXY+PGRpdj48ZGl2Pjxocj5G
cm9tOjxzcGFuPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGFtYXNAYml0c29mcHJvb2Yu
Y29tIiB0YXJnZXQ9Il9wYXJlbnQiPnRhbWFzQGJpdHNvZnByb29mLmNvbTwvYT48YnI+CkRhdGU6
IE1vbiwgNyBBcHIgMjAxNCAyMToyMDozMSArMDIwMDxicj5Ubzo8c3Bhbj4mbmJzcDs8L3NwYW4+
PGEgaHJlZj0ibWFpbHRvOmdtYXh3ZWxsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfcGFyZW50Ij5nbWF4
d2VsbEBnbWFpbC5jb208L2E+PGJyPkNDOjxzcGFuPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWls
dG86Yml0Y29pbi1kZXZlbG9wbWVudEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQiIHRhcmdldD0iX3Bh
cmVudCI+Yml0Y29pbi1kZXZlbG9wbWVudEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ8L2E+PGJyPgpT
dWJqZWN0OiBSZTogW0JpdGNvaW4tZGV2ZWxvcG1lbnRdIFdoeSBhcmUgd2UgYmxlZWRpbmcgbm9k
ZXM/PGJyPjxicj48ZGl2Pjxicj48L2Rpdj48ZGl2Pk9uY2UgaGVhZGVycyBhcmUgbG9hZGVkIGZp
cnN0IHRoZXJlIGlzIG5vIHJlYXNvbiBmb3Igc2VxdWVudGlhbCBsb2FkaW5nLiZuYnNwOzwvZGl2
PjxkaXY+PGJyPjwvZGl2PjxkaXY+VmFsaWRhdGlvbiBoYXMgdG8gYmUgc2VxdWFudGlhbCwgYnV0
IHRoYXQgc3RlcCBjYW4gYmUgZGVmZXJyZWQgdW50aWwgdGhlIGJsb2NrcyBiZWZvcmUgYSBwb2lu
dCBhcmUgbG9hZGVkIGFuZCBjb250aW5vdXMuPC9kaXY+Cjxicj48ZGl2PjxzcGFuIHN0eWxlPSJm
b250OiAxMnB4L25vcm1hbCBIZWx2ZXRpY2E7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWlu
ZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxv
YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1zcGFjZTogbm9ybWFs
OyBmb250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1hbDsiPlRhbWFzIEJs
dW1tZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQ6IDEycHgvbm9ybWFsIEhlbHZldGljYTsgdGV4
dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyBmb250LXNpemUtYWRq
dXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1hbDsiPjxiciBzdHlsZT0iZm9udDogMTJweC9u
b3JtYWwgSGVsdmV0aWNhOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsg
bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBu
b3JtYWw7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyI+Cjxz
cGFuIHN0eWxlPSJmb250OiAxMnB4L25vcm1hbCBIZWx2ZXRpY2E7IHRleHQtdHJhbnNmb3JtOiBu
b25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNp
bmc6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3aGl0ZS1z
cGFjZTogbm9ybWFsOyBmb250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1h
bDsiPjxhIGhyZWY9Imh0dHA6Ly9iaXRzb2Zwcm9vZi5jb20vIiB0YXJnZXQ9Il9wYXJlbnQiPmh0
dHA6Ly9iaXRzb2Zwcm9vZi5jb208L2E+PC9zcGFuPjwvc3Bhbj48L2Rpdj4KPGJyPjxkaXY+PGRp
dj5PbiAwNy4wNC4yMDE0LCBhdCAyMTowMywgR3JlZ29yeSBNYXh3ZWxsICZsdDs8YSBocmVmPSJt
YWlsdG86Z21heHdlbGxAZ21haWwuY29tIiB0YXJnZXQ9Il9wYXJlbnQiPmdtYXh3ZWxsQGdtYWls
LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pjxicj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij5PbiBNb24sIEFwciA3LCAyMDE0IGF0IDEyOjAw
IFBNLCBUYW1hcyBCbHVtbWVyICZsdDs8YSBocmVmPSJtYWlsdG86dGFtYXNAYml0c29mcHJvb2Yu
Y29tIiB0YXJnZXQ9Il9wYXJlbnQiPnRhbWFzQGJpdHNvZnByb29mLmNvbTwvYT4mZ3Q7IHdyb3Rl
Ojxicj4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog
MHB4OyI+dGhlcmVmb3JlIEkgZ3Vlc3MgaXQgaXMgbW9yZSBoYW5keSB0byByZXR1cm4gc29tZSBi
aXRtYXAgb2YgcHJ1bmVkL2Z1bGw8YnI+YmxvY2tzIHRoYW4gcmFuZ2VzLjxicj48L2Jsb2NrcXVv
dGU+PGJyPkEgYml0bWFwIGFsc28gbWVhbnMgaGlnaCBvdmVyaGVhZCBhbmTigJQgaWYgaXQncyB1
c2VkIHRvIGFkdmVydGlzZTxicj5ub24tY29udGlndW91cyBibG9ja3PigJQgcG9vciBsb2NhbGl0
eSwgc2luY2UgYmxvY2tzIGFyZSBmZXRjaGVkPGJyPgpzZXF1ZW50aWFsbHkuPGJyPjxicj48L2Js
b2NrcXVvdGU+PC9kaXY+PGJyPjxicj48L2Rpdj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gUHV0IEJh
ZCBEZXZlbG9wZXJzIHRvIFNoYW1lIERvbWluYXRlIERldmVsb3BtZW50IHdpdGggSmVua2lucyBD
b250aW51b3VzIEludGVncmF0aW9uIENvbnRpbnVvdXNseSBBdXRvbWF0ZSBCdWlsZCwgVGVzdCAm
YW1wOyBEZXBsb3ltZW50IFN0YXJ0IGEgbmV3IHByb2plY3Qgbm93LiBUcnkgSmVua2lucyBpbiB0
aGUgY2xvdWQuPGEgaHJlZj0iaHR0cDovL3Auc2YubmV0L3NmdS8xMzYwMF9DbG91ZGJlZXMiIHRh
cmdldD0iX3BhcmVudCI+aHR0cDovL3Auc2YubmV0L3NmdS8xMzYwMF9DbG91ZGJlZXM8L2E+PGRp
dj4KPGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEJp
dGNvaW4tZGV2ZWxvcG1lbnQgbWFpbGluZyBsaXN0PHNwYW4+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9
Im1haWx0bzpCaXRjb2luLWRldmVsb3BtZW50QGxpc3RzLnNvdXJjZWZvcmdlLm5ldCIgdGFyZ2V0
PSJfcGFyZW50Ij5CaXRjb2luLWRldmVsb3BtZW50QGxpc3RzLnNvdXJjZWZvcmdlLm5ldDwvYT48
YSBocmVmPSJodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9iaXRj
b2luLWRldmVsb3BtZW50IiB0YXJnZXQ9Il9wYXJlbnQiPmh0dHBzOi8vbGlzdHMuc291cmNlZm9y
Z2UubmV0L2xpc3RzL2xpc3RpbmZvL2JpdGNvaW4tZGV2ZWxvcG1lbnQ8L2E+PC9kaXY+CjwvZGl2
PjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+PGJs
b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAw
LjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQs
IDIwNCk7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsi
Pjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+CgpQdXQgQmFkIERldmVsb3BlcnMgdG8gU2hh
bWU8YnI+CkRvbWluYXRlIERldmVsb3BtZW50IHdpdGggSmVua2lucyBDb250aW51b3VzIEludGVn
cmF0aW9uPGJyPgpDb250aW51b3VzbHkgQXV0b21hdGUgQnVpbGQsIFRlc3QgJmFtcDsgRGVwbG95
bWVudDxicj4KU3RhcnQgYSBuZXcgcHJvamVjdCBub3cuIFRyeSBKZW5raW5zIGluIHRoZSBjbG91
ZC48YnI+CjxhIGhyZWY9Imh0dHA6Ly9wLnNmLm5ldC9zZnUvMTM2MDBfQ2xvdWRiZWVzIiB0YXJn
ZXQ9Il9wYXJlbnQiPmh0dHA6Ly9wLnNmLm5ldC9zZnUvMTM2MDBfQ2xvdWRiZWVzPC9hPjxicj5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KQml0Y29p
bi1kZXZlbG9wbWVudCBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpCaXRjb2luLWRl
dmVsb3BtZW50QGxpc3RzLnNvdXJjZWZvcmdlLm5ldCIgdGFyZ2V0PSJfcGFyZW50Ij5CaXRjb2lu
LWRldmVsb3BtZW50QGxpc3RzLnNvdXJjZWZvcmdlLm5ldDwvYT48YnI+CjxhIGhyZWY9Imh0dHBz
Oi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2JpdGNvaW4tZGV2ZWxvcG1l
bnQiIHRhcmdldD0iX3BhcmVudCI+aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMv
bGlzdGluZm8vYml0Y29pbi1kZXZlbG9wbWVudDwvYT48YnI+Cjxicj48L2Jsb2NrcXVvdGU+PC9k
aXY+PGJyPjwvZGl2PjwvZGl2Pgo8L2Rpdj48L2Rpdj4KPC9ib2R5Pgo8L2h0bWw+Cg==

--_1555FEC0-E1BD-4E67-AEFA-487462CF1D89_--

--_3de1e55d-a546-4f49-9371-5ae7e50d08c3_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
--_3de1e55d-a546-4f49-9371-5ae7e50d08c3_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline