Re: XT nodes dropping. I am concerned about adoption.

[Peter Tschipper]

As to the number of XT nodes, I believe there has been a DDoS attack going on today.

https://www.reddit.com/r/bitcoinxt/comments/3iumsr/udp_flood_ddos_attacks_against_xt_nodes/

On 29/08/2015 3:42 PM, Colin H. wrote:

I hope there are some bright ideas as to how to get Bitcoin XT adopted by miners because right now it's looking pretty bleak. I don't mean to be a negative Nancy but there needs to be a real campaign and concerted effort to bring this change about.

The number of XT nodes are dropping. Does anyone know of a specific reason why?

It seems like there is a lot of negative talk at bitcointalk about it (and that's probably because that's all that is allowed with the censorship). But that is what people are seeing because we have a dictator of sorts running all major Bitcoin social media sites.

I still don't have an answer for how to defeat the censorship, but if 0.11.B is going to come out to fix some issues that are preventing miners from using it, then this needs to happen yesterday. I know devs are working hard, but this is a race.

--
You received this message because you are subscribed to the Google Groups "bitcoin-xt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoin-xt+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Hearn]

Remember the "stress test" guy thinks he's helping bring about bigger blocks by DoSing the network too. Some people are just idiots.

WRT adoption - Gavin and I will go talk to some miners next week. I suspect having the possibility of more power dangled in front of them by BIP 100 means they aren't going to support any other option now regardless of what the economic majority thinks. But we can try anyway.

The big, obvious risk for BIP 100 is that Jeff produces an implementation, it doesn't get consensus, Core doesn't merge it, and then the big mining pools decide to apply the patches anyway. I don't think Jeff would do all the work needed to create a fork like XT. It's quite a bit of effort. Adopting the patches anyway would be inconsistent with their past actions but they already changed their minds about 8mb, so who knows. At that point we'd potentially have a fork of the network happening onto a ruleset that isn't actually downloadable by ordinary users!

We'll probably put a few more things into the next release along with the mining fix. I'll work on it this week. But most mining pools already customise the source code, they don't need releases anyway, they can apply the patches whenever they want. Therefore it's not a super high priority.

Ultimately XT just gives the community another option. It's up to the wider Bitcoin world to take it. If the community collectively decides that this whole decentralisation thing is too dangerous and unstable to be worth it, well, I guess that means lots of people will lose interest and drift away. There's no point in replacing central bankers with central developers.

[NxtChg]

The job of miners is to collect our votes, unfortunately right now due to all the complicating factors they are doing a very poor job.

So we need a more direct way to vote and also to make the other side take us more seriously. It's way too easy to just dismiss XT when one block is found once every 2 days.

Would it be a realistic scenario if the economic majority focused on grabbing enough hashing power to make a dent or even overpower the BIP100 miners? After all, we're paying their bills and salaries.

----

Checkpointing is also not out of the question. If XT gets, say, 40% of hashing power and then most of the Bitcoin companies switch to it, it's doubtful that the old miners will try the 51% attack - they are in the business of making money and are not suicidal.

Economic majority has the power of money, so it needs to use it.

[Ross Nicoll]

If the economic majority was interested in pouring funds into changing
away from the current mining pools, I would have thought we'd see them
be more interested in infrastructure projects before now. A major split
from the miners would also introduce all sorts of risks, such as the
miners going on a 51% attack rampage with what amounts to vastly more
resources than can be reasonably assembled (to get enough hardware to
defend would most likely mean finding a chip manufacturer to bulk
produce mining hardware, to give you an idea of scale). If that option
was to be pursued, it would seem to make more sense to move away from
SHA256 and onto one of the more ASIC-resistant algorithms, or at least
one that doesn't have current ASIC hardware.

I'm not saying that's a good idea, I'm saying that's about the only way
to stop the miners from swatting the breakaway chain like a fly.

Ross

[NxtChg]

>If the economic majority was interested in pouring funds into
>changing away from the current mining pools, I would have thought we'd see
>them be more interested in infrastructure projects before now.

"Before now" the situation was different. If they want a better future with growing business instead of a gradually decaying ecosystem, they should act now.

I am not saying it will be easy, but is there any other strategy to win? Because it sure looks like a spectacular flop at this point.

[dfwcoin]

Why do the miners consider the BIP100 8MB block an improvement (safer) over the dynamically increased XT blocks?

Why do we say the miners vote for BIP100 and not BIP101? Don't they both rely on their respective block tags to vote? Moreover, I'm running an XT node and think it's fun to follow the adoption rate of nodes, but does node adoption really make a difference? Isn't this a miners decision for both BIP100 or 101?

Thanks-

[Tom Harding]

Running a node makes a huge difference. It tells miners that there is
network support for them to eventually produce >1MB blocks. Every
single node is very important.

[Tom Harding]

On 8/30/2015 5:03 AM, NxtChg wrote:
> Would it be a realistic scenario if the economic majority focused on grabbing enough hashing power to make a dent or even overpower the BIP100 miners? After all, we're paying their bills and salaries.
>

Realistically, the way to do this is to win the minds of miners and
pools. We have the advantage of being correct. Gavin and Mike have
written many eloquent words on the subject, which can be drawn from.
The objections have been met forcefully, and there is now academic
research that supports BIP 101.

To miners, I ask: when you entered bitcoin, how much did you see it
growing in 20 years? Did you not envision 80x more people using bitcoin
than today? BIP101 is merely a concrete plan to allow room for the
growth you already expected.

> Economic majority has the power of money, so it needs to use it.
>

It's possible, but it would probably take new money. I doubt BitPay has
enough just sitting around to start up a big miner farm.

[NxtChg]

>Realistically, the way to do this is to win the minds of miners and pools. We have the advantage of being correct.

That would be the best scenario, but it doesn't look realistic. It doesn't look like miners are acting rationally.

They have at least two major reasons to vote for BIP100:

1) they fear the split and prefer a safer, short-term path of things staying the same
2) BIP100 gives them more control

At this point it looks (to them and to the rest of the world), that they are completely in charge, and that the "economic majority" can do absolutely nothing.

And XT looks like a deflated balloon, pardon the metaphor. Convincing anybody from that position would probably be rather difficult.

But OK, let's see how it goes.

>It's possible, but it would probably take new money. I doubt BitPay has enough just sitting around to start up a big miner farm.

Mining is a profitable business, so even in bad conditions you can operate it at just a small loss, so grabbing enough hash power won't actually cost you 100% since it pays for itself.

[Tom Zander]

On Sunday 30 Aug 2015 21:54:10 NxtChg wrote:
> Mining is a profitable business, so even in bad conditions you can operate
> it at just a small loss, so grabbing enough hash power won't actually cost
> you 100% since it pays for itself.

Assuming you can get the hardware, this week, not in 3 months.
--
Tom Zander

[NxtChg]

>Assuming you can get the hardware, this week, not in 3 months.

If there is a will, we can start thinking about ways.

I sure hope our strategy is not:

a) try to convince miners
b) give up

[Ivan Brightly]

Let's not exaggerate the position that various big block proposals are in. Sure, BIP100 is in the lead for miner support, but it doesn't have the industry or dev support necessary to be implemented. 

The 9 merchants that have indicated support for BIP101 have not indicated support for BIP100, which makes for an impasse at the moment - aka, no change since miners can't implement changes without the community nor vice versa.

I doubt Gavin and Hearn decided to contribute to XT to see what happens in < 30 days - this is a multi-month or multi-year process. Give it time and lets see what sort of consensus is formed around BIP101 or any other proposals.

[Tom Zander]

Agreed. The problem here really is one we should have seen coming. The
'other' team has been fighting dirty for years, has had the ear of large miners
for months.

If I learned anything from 'house of cards' its that when the only thing you
care about is the power that the end result gives; you are to be feared.

Never underestimate those people.
--
Tom Zander

[NxtChg]

>The problem here really is one we should have seen coming.
>The 'other' team has been fighting dirty for years, has had the ear of large miners for months.

+1

Current situation took XT side by surprise, so we need to regroup and come up with a new strategy, and announce it clearly for people to stop feeling depressed and lost.

Grabbing hash power is the best I could think of, maybe someone can suggest something better. It doesn't have to be a single strategy too.

----

And it requires stronger leadership. Saying things like:

> Ultimately XT just gives the community another option. It's up to the wider Bitcoin world to take it. If the community collectively decides that this whole decentralisation thing is too dangerous and unstable to be worth it, well, I guess that means lots of people will lose interest and drift away.

is as weak as Obama's "sorry folks, I can't do anything, call your congressman... err... miner". Except we don't have one.

Without leadership nothing will happen, XT will flop and a lot of best and brightest, who gathered around it, will feel betrayed and leave.

[Simon Bitcartel]

If miners get to vote every 3 months to adjust the block size, or every 2 weeks based on some other proposals, it's only fair that users get to vote on a periodic basis to change the proof-of-work algorithm... :-)

[Simon Bitcartel]

That was a joke but BIP100 may have planted the seed in many minds.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010757.html

[NxtChg]

>That was a joke but BIP100 may have planted the seed in many minds.

It was a good joke :) And as every good joke it has a grain of truth in it.

But resistance to this would be insane. This should only be seriously considered in case XT dumps most of the old miners completely and instead creates a clone with democratized mining.

Then we can say to the miners "you have no power here" and the risk of 51% attack will be gone.

[Andreas Schildbach]

Yes, for example my XT node doesn't live for longer than a few seconds
and then dies.

>> <mailto:bitcoin-xt+...@googlegroups.com>.

>> For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to the Google
> Groups "bitcoin-xt" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoin-xt+...@googlegroups.com

> <mailto:bitcoin-xt+...@googlegroups.com>.

[Jorge Stolfi]

[nxtchg:] The job of miners is to collect our votes, unfortunately right now due to all the complicating factors they are doing a very poor job.

Well, the miners have no obligation to do anything.  They are supposed to do what is in their interest.

Suppose that the services say that they want BIP101, but miners controlling 70% of the hashpower anounce that, on 2016-02-01, they will raise their block size limit to 2 MB.  What will happen?

Or suppose instead that those miners say that they have decided to lower the limit to 500 kB. 

[NxtChg]

>Well, the miners have no obligation to do anything. They are supposed to do what is in their interest.

And assessing where the economic majority will be is in their best interest.

Here's some ideas about possible strategies:

1. Try to convince as many miners as possible with rational arguments.

2. The "economic majority", i.e. companies (although people can crowdfund some things too), need to start wielding their economic powers.

It's naive to expect they will get a better future for free.

This includes:
* help protecting from DDoS and other attacks
* support XT mining pools
* try to grab as much hashing power as we can
* help promoting XT
* help getting more companies on board
* reward miners directly or indirectly
* setup more XT nodes
* prepare to block any other block size increases, like BIP100
* [fill in your ideas]
* and in general send a clear message that we will not back down.

Those, who have direct contacts with companies, need to start an organizing effort.

The other side was well-prepared and is not afraid to act, however bad their methods are.

3. If this all fails, start considering other ways of taking power from miners.

"Power is never given, it's always taken".

[Mike Hearn]

I think the best thing to do right now is just build up XT as a healthy project, and not worry too much about the short term.

Unless things change fairly drastically Wladimir isn't going to accept any controversial changes to the block size limit, and they're all controversial including BIP 100. So eventually people will realise how things are and see a healthy XT with contributors getting things done, and rethink their loyalty to Core.

The other possibility is that Wladimir changes his mind and does merge something, probably an implementation of BIP 100 whilst claiming this is totally compatible with his previous statements and what he wanted all along, then the miners all adopt it and the economic majority goes along with it on the grounds that something is better than nothing, even though it's not really what they wanted.

In which case, OK then. As long as the block size keeps ahead of traffic, so be it.

That outcome will still leave the community with serious problems, but they'd be hidden away for another day.

[NxtChg]

>The other possibility is that Wladimir changes his mind and does
>merge something, probably an implementation of BIP 100 whilst claiming
>this is totally compatible with his previous statements and what he wanted
>all along, then the miners all adopt it and the economic majority goes
>along with it on the grounds that something is better than nothing, even
>though it's not really what they wanted.

That's exactly the scenario I am worried about and it looks like the most probable one.

>In which case, OK then. As long as the block size keeps ahead of traffic, so be it.

This passive attitude from our side (not just you) is one of the reasons why XT looks so bad now with its 1.5% of blocks.

Yes, we all hoped that support would be much stronger, but then BIP100 happened and other things, and our side was in limbo for a week. And now what, we just give up?

If there is no firm resolution and no active effort but "meh", people won't treat XT seriously and won't consider switching. You need a will first.

Right now those on the fence are just waiting for the 8 companies to change their minds and XT will be dead, supporters will feel betrayed and disappointed.

And we will have a few more years of stagnation.


I don't know, maybe I am overly-pessimistic. Maybe others would chime in about how they see things.


(btw, finished the "onboard" page yesterday, you can merge it)

[Jorge Stolfi]

And assessing where the economic majority will be is in their best interest.
Here's some ideas about possible strategies:

* prepare to block any other block size increases, like BIP100

* and in general send a clear message that we will not back down.

The problem is that bitcoin says to use the longest chain that you know and you consider valid.  Suppose that, after Jan/2016, the mining majority keeps mining 1 MB or 2 MB blocks even when there is a persistent and growing backlog.  What could the businesses do?  The chain created by those miners will be valid for any clients who accept 8 MB too; since it is the longest, they are obliged to use it.

There may be a minority of the miners creating a branch with 8 MB blocks, but it will not be the longest by any criterion.  If the services forcibly use that branch and ignore the other, they will be violating a basic rule of the protocol.  Their "bitcoin" would no longer be decentralized: it will be a centralized coin implemented by those services and miners.

The bitcoin protocol *by design* gives the ultimate decision power to the majority of miners.  That power was never supposed to get concentrated in 5-6 companies.  But it is.  Now, objectively, bitcoin is in a coma.  It will not be "bitcoin" again until the hashing power becomes widely distributed again.

[Tom Harding]

On 9/1/2015 10:11 AM, NxtChg wrote:
> I don't know, maybe I am overly-pessimistic. Maybe others would chime
> in about how they see things. (btw, finished the "onboard" page
> yesterday, you can merge it)

Be patient. Today, there is only one actual defined path to trigger a
blocksize increase - bip101. The biggest challenge is many don't yet
realize it is needed.

[Gavin Andresen]

On Tue, Sep 1, 2015 at 5:19 PM, Tom Harding <to...@thinlink.com> wrote:

Be patient.  Today, there is only one actual defined path to trigger a blocksize increase - bip101.  The biggest challenge is many don't yet realize it is needed.

Yes, this is a marathon, not a sprint. Lets try to stay focused on taking concrete steps that make Bitcoin (and the XT code and it's software development process) significantly better.

If some other raise-the-blocksize proposal gains consensus, then so be it -- XT is all about pragmatism and not letting the perfect be the enemy of the better.

Or, as Jim Harper wisely said, "keep calm and Bitcoin on."

-- 

--
Gavin Andresen

[Arnoud Kouwenhoven]

The DDoS attack is annoying. Although I don't want the 'bad guy(s) to win', I am also not happy about the extra time and effort (not to mention annoyances) that this takes. I have been happy to run it on 3 nodes as a service back to the community. I don't really keep track of traffic but I think I donate about 1 - 1.5 TB per month to the bitcoin community with these 3 nodes, possibly more.

But I don't want to spend my time fighting to keep a service online that I provide for free, and am considering just taking the nodes offline (or more likely disabling incoming connections altogether). My time should be focused elsewhere.

It is really sad that the attacks on my nodes seem to be coming from the bitcoin community itself, of all places. Full nodes are important to the health of the network and the attacker is really causing full nodes to be run only by companies that care to, or can afford to, set up DDoS protected hosting. This is driving centralization and is hurting the health of the network as a whole. 

If the attacker is reading this mailing list: if you want to centralize bitcoin keep doing what you are doing. You are driving centralization of development, centralization of full nodes and centralization of mining by driving out the regular people with regular servers and regular hosting. Only the big guys will care to defeat your attacks. If that is what you want: good job. Just don't pretend you are helping bitcoin.

So much for the rant. More on topic - what are the options to keep the nodes online? Sure we can all go to DDoS protected data centers but that just increases cost and drives centralization again to certain network segments.

--
You received this message because you are subscribed to the Google Groups "bitcoin-xt" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bitcoin-xt+...@googlegroups.com.

[e6M77kw]

How do you guys notice that they are attacking you? Either, they are completely ignoring me or I'm oblivious to the attack, because my node has been running for 9 days non-stop and I see nothing suspicious....

Op woensdag 2 september 2015 08:03:43 UTC+2 schreef Arnoud Kouwenhoven:

[Mike Hearn]

He doesn't seem to be attacking all nodes. Probably a limitation of his "bitkiller" program.

[Arnoud Kouwenhoven]

One way to find out (and this depends on your ISP) is for your IP to be null-routed as the ISP's DDoS mitigation strategy. This effectively plays right into the attacker's hand, but there you go.

My ISP sent a section of a log that shows udp packets from remote port 53 (DNS) routed to my port 8333. I assume the attackers forge a DNS request packet in such a way that DNS servers send their response to the wrong place (my node), thus shielding their own location and probably amplifying their attack.

I have renamed my Bitcoin XT node by changing the clientversion.cpp file, line:

const std::string CLIENT_NAME("Bitcoin XT");

It *is* still Bitcoin XT, and will have all the network benefits of an XT node. But it just does not broadcast to the world that it is XT. I'll update once I know if this works (ie whether or not it gets attacked again), and then I'll also re-enable the other 2 nodes.

I guess I am running "Not Bitcoin XT" now.

All this made me think about how to mitigate this threat in the future, without needing to shut down nodes or lie about the version. And it made me wonder why all nodes need to service all IP addresses at all. It sounds a bit crazy, but would it not make sense for a node to serve only x% of the IP addresses, ie 10%, and ignore the rest of the world? This could be done randomly, ie 

if (f(IP_NODE) xor f(IP_REMOTE) xor RANDOM mod 10 = 0) {

  // serve request

} else {

  // drop connection

}

All nodes would still get all transactions and all blocks, just not all nodes are accessible to them. It introduces randomness in the network. It would not be possible for anyone to generate a complete set of all nodes and get a list to DDoS. This can be combined with bitcoin running on a random non-standard port to prevent such lists being made with large scale port scanning.

Bootstrapping would get a bit trickier (ie DNS seeds would include addresses that cannot be reached, so more attempts would be needed). I'd need to do some calculations to ensure that nodes would not work as islands (my "gut feeling" says this will not happen, but that is hardly scientific.) Would it be worthwhile pursuing this idea a bit further?

On Wed, Sep 2, 2015 at 8:40 PM, Arnoud Kouwenhoven <arn...@kouwenhoven.net> wrote:

One way to find out (and this depends on your ISP) is for your IP to be null-routed as the ISP's DDoS mitigation strategy. This effectively plays right into the attacker's hand, but there you go.

My ISP sent a section of a log that shows udp packets from remote port 53 (DNS) routed to my port 8333. I assume the attackers forge a DNS request packet in such a way that DNS servers send their response to the wrong place (my node), thus shielding their own location and probably amplifying their attack.

I have renamed my Bitcoin XT node by changing the clientversion.cpp file, line:

const std::string CLIENT_NAME("Bitcoin XT");

It *is* still Bitcoin XT, and will have all the network benefits of an XT node. But it just does not broadcast to the world that it is XT. I'll update once I know if this works (ie whether or not it gets attacked again), and then I'll also re-enable the other 2 nodes.

I guess I am running "Not Bitcoin XT" now.

All this made me think about how to mitigate this threat in the future, without needing to shut down nodes or lie about the version. And it made me wonder why all nodes need to service all IP addresses at all. It sounds a bit crazy, but would it not make sense for a node to serve only x% of the IP addresses, ie 10%, and ignore the rest of the world? This could be done randomly, ie 

if (f(IP_NODE) xor f(IP_REMOTE) xor RANDOM mod 10 = 0) {

  // serve request

} else {

  // drop connection

}

All nodes would still get all transactions and all blocks, just not all nodes are accessible to them. It introduces randomness in the network. It would not be possible for anyone to generate a complete set of all nodes and get a list to DDoS. This can be combined with bitcoin running on a random non-standard port to prevent such lists being made with large scale port scanning.

Bootstrapping would get a bit trickier (ie DNS seeds would include addresses that cannot be reached, so more attempts would be needed). I'd need to do some calculations to ensure that nodes would not work as islands (my "gut feeling" says this will not happen, but that is hardly scientific.) Would it be worthwhile pursuing this idea a bit further?

Arnoud

On Wed, Sep 2, 2015 at 12:07 PM, Mike Hearn <he...@vinumeris.com> wrote:

He doesn't seem to be attacking all nodes. Probably a limitation of his "bitkiller" program.

--

[Steve Myers]

Arnoud, which init system are you using to run your bitcoind (xt) daemon? I've had a much easier time keeping my bitcoin xt node up after switching to systemd since it automatically monitors and restarts the process if it dies.  You can find an example config in the file: contrib/init/bitcoinxt.service.  I used to have to manually re-start my node a couple times a week but haven't had to restart it since switching to systemd.  As always YMMV, good luck.

[Arnoud Kouwenhoven]

Hi Steve,

Thanks.

I use supervise, part of the cr.yp.to daemontools package. It works great for monitoring services including bitcoind and restarts bitcoind perfectly.

In this case bitcoind does not crash. I don't even think udp packets will hit the application even if they get sent to the same port.

in this case the DDoS takes bandwidth and kernel resources to the point where mostly the ISP is unhappy. They null route the IP which means that no one can reach the node.

[Steven Myers]

Hi Arnoud, my bitcoinxt node is running on a resource constrained device (beagle bone) so I suspect my crashes were probably memory related rather than DDoS anyway.  Thanks for the info on daemontools, looks interesting, I’ll give it a try if I run into problems with my systemd config.  

[GGG 2014]

I'm doing two things to aim to get a user-owned full node on XT up and running.  One was to make sure that I have home miners, even though *only* second hand S1 units running whilst there is sun on my solar panels.  The second was to compile from src bitcoin-qt bitcoin_XT.

It is only a raspberry pi B2, so quad ARM7 at 900MHz; only 1G of RAM.

In two weeks, its download of the full blockchain to a rather busy usb storage stick has progressed by only two months, and it is still a year behind.

I started it from 21GB of blockchain up to 2013 which I had lying around somewhere.

I'd have liked to get it to perhaps a month to go with something like

bootstrap.dat
but that got discontinued.

Are there any plans to make a July2015bootstrap.dat or comparable distributable?

Any other advice for XT-ers for how to get a full node to complete its blockchain download?

[Jameson Lopp]

Assuming that you have a decent broadband internet connection, your bottleneck is going to be the low powered CPU. Bootstrapping has been deprecated because it's generally faster now to just download historical blocks from peers on the network. Regardless of if you are using the bootstrap file or downloading blocks from peers, your node must perform the CPU intensive verification of the historical data.

The only way I can think of speeding up this process is to run a node on a more powerful machine and once it is caught up to the tip of the blockchain, copy over the data directory to your raspberry pi so that it doesn't have to perform all of the verifications on the historical data.

- Jameson

[Chris Wheeler]

Also worth mentioning that, afaik, XT and Core function in exactly the same way with regards to downloading and verifying the chain. So you would have the same issue with Core.

Could the USB stick I/O be an issue?

[GGG 2014]

Thanks for suggestion.

I got up to date on a spare i5 quadcore which could use the 21GB
bootstrap.dat but that mac address has inexplicably lost its ability
to get a dhcp off the home router, so it worked once only and is now
offline. Copying that (non-xt) blockchain, another bitcoin-qt on my
underpowered old single-core email pc is now fully up to date.
Another copy of That BTC blockchain was re-indexing right from the
start of 2009 on my bitcoin-qt 0.11 XT raspberry pi until the
usb-stick went wrong (too many rw cycles??) . For now I've
discontinued using that rPi for bitcoin_XT as it has insufficient
memory and media unsuited to continuous rw swap activity. Its cpu was
fine - it was the swapfiles which limits it, and reindexing the whole
history of the blockchain for bdb5.1 I'd been charting the slowdown
of reindexing for a couple of weeks.

For record keepers, at this location with 36MB/s broadband, an i5
quadcore with ample resources took about one week to get from
bootstrap.dat to Sept.2015 up to date.
My 1.8GHz single core desktop pc with 512MB RAM and plenty of swap
(1200MB swap in use at present) took four days to catch up 12 days
worth of blockchain and its catching-up rate averages 3x.
I was at least partly looking at resource requirements. My next
attempt to do a bitcoin-qt 0.11 XT full node will be:
on a clean install of linux, on a duel-core 1.8GHz to which I've just
added a second GB of memory.
so that could be described as "any-old pc with >80GB of spare HDD and
2GB of ram"

Would you like me to say how that goes?


At this location, where the ISP does not do IPv6, reading and indexing
bootstrap.dat
proceeded in about two full days, by comparison to >2 months to get
the blockchain up to April 2015 by p2p peers. That all seems
inconsistent with what I'd been reading online about the blockchain
synch time for BTC.
bootstrap.dat worked >10x faster than peers. A new BTCjuly2015
bootstrap.dat (up to very confirmed immutable transactions) would be
worth a .torrent or .tar.gz for others like me.

Meanwhile on the mining,
stratum+tcp://eu.multipool.us:3345
says that it is mining "BXT" bitcoin XT to "the upstream pool". ????

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "bitcoin-xt" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/bitcoin-xt/IoGjEt89CeM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to