Gold collapsing. Bitcoin UP.

[Zangelbert Bingledack]

@Dusty

I think all of them are at least on record as saying they want an increase "eventually." I'd like a list of what size each would support right *now* if it were a simple Core-issued hard fork via block height (flag day) with anything less than a six-month activation window.

 

[go1111111]

Why isn't there a list of preferred blocksize caps (via hard fork, since that is your claim) among Core devs?

Compiling this list would be a great use of Jonny's boundless energy on this topic. Jonny, I will actually help you with this if you're up for it. Let me know. Ideally we'd get the answers from Core devs, as well as other prominent block size debate participants.

 

[Dusty]

@Dusty
I think all of them are at least on record as saying they want an increase "eventually." I'd like a list of what size each would support right *now* if it were a simple Core-issued hard fork via block height (flag day) with anything less than a six-month activation window.

From what I know, there is no plan to increase the block size with an hard fork. They want to increase it by various other means rolled out by softforks (segwit, Schnorr signatures, etc).

 

[freetrader]

This miscommunication has caused problems and divisions in the community. Once more people realize this, then we do not need to do a symmetric hardfork that splits the chain and community in two. We can just sit down in a calm non confrontational way and do a careful, cautious and sensible hardfork, with an unnecessarily high level of strong consensus across the community.

You are arguing disingenuously once again. It is not miscommunication over the last years that has caused this division. The culprits are clearly to be found among Core leadership (now Blockstream) and in its refusal to compromise on anything despite best efforts by various previous parties.

I for one, am not sitting down for a meeting that cannot produce any agreement, nor the mythical consensus about which you fantasize. Perhaps consensus was once possible within the small group that is Core.
Even those days are long past, as evidenced by Core's inability to deliver on simple promises - it freely admits that it has no control even over its own release process when it comes to delivering things agreed in meetings. The only thing you people are good at is delivering promises.

If you (Core) are able to conceive of a "careful, cautious and sensible hard fork", then implement it in software, create a PR on your own github, and let the community cheer you on, or not.
[doublepost=1470210651][/doublepost]

Compiling this list would be a great use of Jonny's boundless energy on this topic. Jonny, I will actually help you with this if you're up for it. Let me know. Ideally we'd get the answers from Core devs, as well as other prominent block size debate participants.

They're all known to be able sign statements from previous occasions.

I would support this call for every Core developer (and I mean - EVERY ONE) to sign their name/handle cryptographically to the on-chain scaling choice that they support in the IMMEDIATE term.
Then let's see if there is any significant HF support among the entirety of Core.

Those who cannot be reached or abstain from voting should be listed as such.

 

[Zarathustra]

@jonny1000

Also, if such a list existed and we had a clear statement from the Core committers and that they will release a fork to 2MB if people stop "supporting Classic" (mining Classic?), I am sure people would stop supporting Classic and give Core one last chance, but Core is miles from anything like this.

That would be very disappointing. It would prove that the average Bitcoiner is even dumber and more slavish and masochistic than the average citizen, if he is ready to follow those totalitarians, vandals, sadists and traitors once more and give them another last chance.

 

[freetrader]

That sounds sweetly familiar:

 

[freetrader]

Since Ethereum community has recognized the existence of ETC on his official blog, BW will adhere to the neutral and non-evil attitude and respect the choice and actual demand of miners.

https://www.reddit.com/r/btc/comments/4vx6ci/bw_announcement_about_online_etc_mining_pools_and/

Well, that's good to know. Can't be evil (unless lack of indicators permits).

I wonder how far along they got with the "choice" part of Bitcoin block size. Oh wait, there were agreements in the way. But haven't they expired?

 

[Zangelbert Bingledack]

Once more people realize this, then we do not need to do a symmetric hardfork that splits the chain and community in two.

Ah I finally see your complete position. You actually think a split is bad. If you didn't, you would agree with me that we should have a symmetric fork with no hashpower threshold. I do agree with you that an asymmetric fork like Classic (probably) presents an unnecessary danger of loss in forkbitrage, so should have a higher consensus threshold so as not to be subject to trading, but there is obviously so much controversy on this and many other points (as well as, by now, general mistrust of Core) that splits will be inevitable in the future. Many, many splits, each with market referendums.

I think splits are good. Very good. A great boon to Bitcoin. In fact, irresponsible not to do. Let's split and go our separate ways and see which the market supports and which gets the trading network effect (it won't be both, not for long, unless the economy really needs both - it won't for this particular fork at least). Actually, if the split goes through and doesn't immediately fall toward zero you'll be investing on the big block side with us, right?

 

[freetrader]

Counterpoint from Meni Rosenfeld (please critique him publicly, @jonny1000, if you feel your argument actually has any legs):

https://fieryspinningsword.com/2016/08/03/and-god-said-let-there-be-a-split-and-there-was-a-split/

My favorite passage, which I think can stand on its own and quite simply nails it:

I’ve been criticized with the argument that a split will never happen, because the majority side will >50% attack the minority and kill it. Sure, it could happen, and I can’t give any guarantees that it won’t happen. But why should it happen? Miners on the majority side might think they are morally justified in attacking the minority. I am here to say that, no, the minority has a right to coexist, and you are no more morally justified to attack it than banks are justified in attacking Bitcoin in general. They might also think they are financially incentivized to attack the minority, to keep their own favorite chain stronger. I am here to say that, no, they’d be cutting down the branch on which they’re sitting – by condoning attacks on minority splits, they are promoting a version of Bitcoin (again, “Bitcoin” is not just Bitcoin) were splitting is frowned upon, a version with tyranny of the majority and without the potential to evolve – a version of Bitcoin which is weaker overall.

Thank you, Meni.

 

[jonny1000]

Why isn't there a list of preferred blocksize caps (via hard fork, since that is your claim) among Core devs

The Core team is already working on so much in the area of capacity increases:

• SegWit soft-fork to increase effective capacity by around 80%
• Schnorr Signatures
• Aggregated Signatures
• MAST
• Discussion on a hardfork to increase the size limit of non witness data

a 95% consensus requirement is innocuous at least since it will be met immediately

I totally agree, it will be easy, just like the 95% was easy for all the soft-forks which keep happening. Whether you agree if its necessary or not does not matter, since it is so easy to achieve

Like some others here, I don't understand your fixation with stamping out all support for Classic before moving on to more productive discussion.

This is because there has been a massive campaign across the community to activate Classic. As I explained in this comment trying to persuade Greg some compromise is ok:


The campaign has been aggressive. Had it not occurred the Core team would have done 2MB ages ago. The Core teams priority was ensuring Classic was defeated due to its dangerous implementation methodology. They could not HF to 2MB otherwise the network could have split into three. At the same time they developed a safe softfork method of getting to 2MB, called SegWit.

the activation period is longer than 28 days (60 seems good to me)

Gavin said in 2013 that it should be at least 6 months. I agree with that.

create a PR (with help from a dev if you're not a dev) where the HF is symmetric

If you (Core) are able to conceive of a "careful, cautious and sensible hard fork", then implement it in software, create a PR on your own github, and let the community cheer you on, or not.

The Core team will do this anyway. I expect this to be released shortly after the activation of SegWit. I expect it will be a Soft-Hardfork. 5 Core developers already committed to do this within three months of the release of SegWit. It looks like one developer is already working on this.

Do you not understand that almost everyone is happy to do a 2MB hardfork. However most of the Core devs are absolutely determined not to appear to be forced into the move and not to engage in political compromise or any other kind of political activity. It must be demonstrated that you can not force a HF by political means, otherwise Bitcoin has failed in the eyes of many. This makes it very difficult for the Core team to create a PR during times of such high political tension over the issue.

follow those totalitarians, vandals, sadists and traitors

If other people here do not think this language is appropriate or helpful, please point it out.

Ah I finally see your complete position. You actually think a split is bad. If you didn't, you would agree with me that we should have a symmetric fork with no hashpower threshold.

Counterpoint from Meni Rosenfeld (please critique him publicly, @jonny1000, if you feel your argument actually has any legs):

I agree that people are free to do a symmetric HF with no threshold and I agree with Meni. My view is that there is no need to do one now for reasons associated with capacity, since there is broad consensus across the community on the issue. There is no significant opposition to the idea of large capacity increases.

However, if you want to do a symetric HF with no threshold, go ahead. I will not try and stop you, I probably will not support you, but you shouldn't mind about that. I also recognize that at some point in the future this is likely to occur.

What I do mind is if you try to launch an asymmetric hardfork with a 75% threshold, which is likely to cause a lot of damage to the system before eventually being defeated.

 

[Zangelbert Bingledack]

@freetrader

I don't really see Meni's point on the financial side. The minority chain may turn around and try to 51% the other chain, so it seems financially prudent to kill it before it has the chance. Also, Meni mentions the oscillation problem where miners mine one coin for two weeks then the other, requiring a new difficulty retargeting algorithm...or PoW change. I strongly suspect PoW change is essential and that ETH and ETC are treading on thin ice without it (normative prohibitions on 51% attacks and the public facing nature of the current mining pools will probably save it though).

@jonny1000

|Do you not understand that almost everyone is happy to do a 2MB hardfork. However most of the Core devs are absolutely determined not to appear to be forced into the move and not to engage in political compromise or any other kind of political activity. It must be demonstrated that you can not force a HF by political means, otherwise Bitcoin has failed in the eyes of many. This makes it very difficult for the Core team to create a PR during times of such high political tension over the issue.

Ack, just when you had started making some sense

And you also evaded my question about which devs support what level of hardfork blocksize cap increase. I assume it's because you don't know, but then why do you claim to know?

Most of us don't want this rube-goldbergesque piddling level of on-chain scaling Core is proposing. If they would merely release a 2MB hard fork most Classic miners would drop Classic and support it. I have no idea why you think people are somehow wedded to Classic. Campaign is irrelevant; people just want a fork from anyone reputable. If anyone didn't take Core's hardfork to 2MB it would only be because they hate Core so much that they insist on forking away. But waiting longer is certainly not going to help that, only make it worse for Core.

Persistent splits are good. Core is adding huge technical debt and complexity* for tiny capacity increases when bigger blocks are almost certainly safe. But let's let the market decide which is better. I'd love the chance to take money away from people who hold the views mentioned in the paragraph I quoted from you, by selling off their side of the fork. And they can look forward, in their ignorance, to taking our money away. Win-win, no downsides except PoW change, let's do it!

*As they say, "Do not invest in what you do not understand." Investors won't like this frankenbitcoin if they have a choice.

 

[freetrader]

@jonny1000 :

What I do mind is if you try to launch an asymmetric hardfork with a 75% threshold, which is likely to cause a lot of damage to the system before eventually being defeated.

I'm still thoroughly unconvinced by your refrain that the likelihood of defeat would be high with the Classic fork if it were to activate with large miner support.

Though there may be a few other bumps (like the replay attack vector) that were certainly not raised w.r.t. the Classic fork (not even by Core luminaries) until after serious inquiry started into the viability of hard forks, and the actual ETH/ETC fork demonstrated this risk in reality.

It may be argued that Core would not have raised this to maintain an edge with which to defeat an asymmetric Classic fork, but I reject that. You have been trying to argue all angles against Classic on this forum, and this one escaped you for a long time (seemingly until ETH).
And, as we currently observe, even for ETH/ETC, it seems to have become a manageable risk, once the issue was realized and mitigated by exchanges it no longer threatens the viability of the fork.

I'm pointing this out so you realize that you *still* don't have a solid case against the Classic project. The only thing that has failed it so far is the mining cartel and the mysterious glue (sticky rice?) that holds it together.

~~~{~{@ X @}~}~~~​

Do you not understand that almost everyone is happy to do a 2MB hardfork. However most of the Core devs are absolutely determined not to appear to be forced into the move and not to engage in political compromise or any other kind of political activity. It must be demonstrated that you can not force a HF by political means, otherwise Bitcoin has failed in the eyes of many. This makes it very difficult for the Core team to create a PR during times of such high political tension over the issue.

Shall we go over the list of political strategies together and identify the ones EXCEPT compromise (!) which Core has been happy to pursue until now, and still does?

https://en.wikipedia.org/wiki/Political_strategy

Probably a non-exhaustive list:

• 1.1 Censorship
• 1.2 Compromise
• 1.3 Discrediting
• 1.4 Fear mongering
• 1.5 Heroism
• 1.6 Lying
• 1.7 Obstructionism
• 1.8 Passing the buck
• 1.9 Placating
• 1.10 Plausible deniability
• 1.11 Religion-based strategies
• 1.12 Smear campaign

Do you want to reflect on that a little, or still carry on telling me Core does not play politics with Bitcoin?
I've highlighted the green ones which I think are fairly easy to find examples.
Passing the buck - you're close, always trying to blame any missed milestones on Classic/XT/whatever the bogeyman du jour is at Core.

Religion-based strategies? Not sure that Core has been using this one yet. Hard to deploy among a mostly educated audience. And it's one that cuts both ways in isolated, unworthy examples which fall under Discrediting as far as I'm concerned. Still need to wait and see how that plays out fully.

Plausible deniability? Not sure if we can count the latest California social meeting as an incident against this category.

My point here is not to claim either side is innocent on all counts, far from it. Merely to let you realize that your portrait of an apolitical Core misses the mark by an embarassingly long shot. Now that's not even plausibly deniable.

What I'm most curious though, is why Core excludes Compromise, seemingly at all costs.
You argue they don't want to appear forced. The entire point of compromise is to let both sides come to an agreement that saves face. Seeing as the miners/pools in HK are on the other end of this equation, it seems they are being made to lose face (and more) because of Core's unwillingness to compromise.

 

[Roger_Murdock]

Why threaten? I think both a PoW change fork and a non-PoW change fork should be created. Let's see how it all shakes out. Potentially it could all be done pseudonoymously so no one ties their reputation to it.

The miners need to know they need to shit or the pot will be taken from them. They owe us nothing, we owe them nothing. We just want to pay them to put transactions in blocks and they are failing to do so. If a plumber could not get to my plumbing issue and told me he was going to charge me extra because he was so busy, I would find a different plumber. That kind of shit only works in a monopoly position and I have little doubt there are plenty of people who want our money.

Sorry, meant to respond to this earlier. To answer your question, I think my suggested approach would have a higher chance of being successful. Either the miners are "scared straight" by the credible threat of a PoW change and raise the block size themselves or they refuse and the necessity of a PoW-changing fork hopefully becomes undeniable to the supporters of on-chain scaling such that everyone gets on board. The easy part of forking is releasing the code for a fork. The tricky part is getting people to use and value it. A PoW-changing fork is more likely to be successful in that regard if it's a clear Schelling point, i.e. if it lends itself to being viewed as "the official" fork attempt around which the pro-scaling forces should rally.

And it occurs to me that this is where the anti-hard fork crowd is actually sort of onto something. I said this earlier re: the risk of a persistent chain split:

So sure, a minority of the network might decide to stay on a 1MB4EVA chain following a hard fork to bigger blocks (as is their right). But that "risk" is no different in principle than the risk that a disgruntled minority of big-blockers might, at any time, fork to a new chain that allows for meaningful on-chain scaling.

But, in fact, there is a difference between the two situations. The reason that the former situation probably does present a greater "danger" of a chain split is because the "disgruntled minority's" coordination problem is so much easier to overcome. Essentially there is no coordination problem because the status quo is such an obvious Schelling point. If 80% of the herd heads off in a new direction (i.e., forks) that the remaining 20% strongly opposes, that minority doesn't really have to "organize" to resist the change; they can simply choose to continue on the original course. On the other hand, if a disgruntled minority (or, for that matter, a disgruntled majority) wants to head off in a new direction, they have to coordinate their exit such that they leave at the same time and head in the exact same direction.

But I'm increasingly inclined to view this as an advantage of hard forks. The fact that they make it easier for a minority to keep the protocol they want is a good thing. That just enables more people to satisfy their preferences with respect to the protocol. Again, we should only expect a meaningful chain split to persist if the benefits (in the form of greater preference satisfaction) outweigh the costs (in the form of reduced network effect).

 

[jonny1000]

And you also evaded my question about which devs support what level of hardfork blocksize cap increase. I assume it's because you don't know, but then why do you claim to know?

Pretty much all of them, except perhaps one or two less prominent ones
[doublepost=1470226586][/doublepost]

Do you want to reflect on that a little, or still carry on telling me Core does not play politics with Bitcoin?

I never said Core doesn't play politics. I said many believe a HF should not occur for political reasons. Preventing a HF using political measures however, is probably seen as fine.
[doublepost=1470226630][/doublepost]

My point here is not to claim either side is innocent on all counts, far from it.

I agree the tactics used on both sides are almost identical.
[doublepost=1470226894][/doublepost]

Essentially there is no coordination problem because the status quo is such an obvious Schelling point. If 80% of the herd heads off in a new direction (i.e., forks) that the remaining 20% strongly opposes, that minority doesn't really have to "organize" to resist the change; they can simply choose to continue on the original course.

I totally agree with this great point. On this forum I have been trying to illustrate the tremendous power of the status quo, and why such a strong consensus is needed to overcome it, such a consensus will have no problem getting 95% miner support. This is especially true when you give the status quo a massive asymmetric advantage.

It is this power of the status quo which gives Bitcoin its value in the eyes of many, since one cannot create more than 21 million coins without having the large consensus necessary to overcome the power of the status quo. (By the way you cannot create more than 21 million coins with a softfork, from the perspective of the people running existing nodes. Sure you can create new coins that upgraded clients see (which you can do without a soft or hard fork by the way), but the existing nodes will not recognize them as valid coins.)

If Bitcoin is still around in 25 years time, the community may look very different. After a large theft or humanitarian catastrophe there may be calls to issue new coins. I am now convinced @Roger_Murdock will join me, in responding by saying to the HF advocates "the status quo is such an obvious Schelling point", it is too powerful, you cannot overcome it because there is significant opposition. Therefore do not try and HF. This is the real heart of the blocksize debate. I feel very positive about Bitcoin now, as I think after this chapter, many potential allies in the eventual 21 million debate, have learnt a very useful lesson.

 

[Zarathustra]

The campaign has been aggressive. Had it not occurred the Core team would have done 2MB ages ago.

Says the supporter of the true aggressors.

The Core team will do this anyway. I expect this to be released shortly after the activation of SegWit. I expect it will be a Soft-Hardfork.

5 Core developers already committed to do this within three months of the release of SegWit. It looks like one developer is already working on this.

LOL, yes, the catholicist 500KB aggressor who thinks slavery is okay and non-catholicist preachers should be killed. That's one of those geniuses whom you are marching in fours with.

Do you not understand that almost everyone is happy to do a 2MB hardfork. However most of the Core devs are absolutely determined not to appear to be forced into the move and not to engage in political compromise or any other kind of political activity.

How dumb do you think we are? The core aggressor is fully engaged in political fights; sometimes 24 hours a day.

It must be demonstrated that you can not force a HF by political means, otherwise Bitcoin has failed in the eyes of many. This makes it very difficult for the Core team to create a PR during times of such high political tension over the issue.

That's why we have to split. Zero desire to be artificially united with those tyrants (totalitarians, vandals, sadists and traitors). That's your business; not ours. We are not masochists.

If other people here do not think this language is appropriate or helpful, please point it out.

You will not find many. It's your false language that an overwhelming majority dislikes. (If you are still not able to realize it).

I agree that people are free to do a symmetric HF with no threshold and I agree with Meni. My view is that there is no need to do one now for reasons associated with capacity, since there is broad consensus across the community on the issue.

If you define 5 pool admins and the paid blockstream devs as the community, then yes.

 

[Zangelbert Bingledack]

Essentially there is no coordination problem because the status quo is such an obvious Schelling point.

This does feel exactly like what's been going on, and is a factor I hadn't been including under the idea of "forking friction." Eventually something has got to give, but determining a solid Schelling point is hard. 2MB seems the most numerically obvious one.

My long-held dream of fork arbitrage has come true and is going off apparently without a hitch (except replay attacks), with almost universal uptake by exchanges. The infrastructure for smooth forking, which I previously could only hope would one day be in place, now seems to be ready and working. This should allow for some really nice leeway, like releasing a bunch of forks at once and letting them get priced.

"1MB, 2MB, 4MB, 8MB. Fight!"

If it were futures contracts it would be all the better, but just letting them go onto exchange at fork time and letting the Schelling point be determined by the market process seems viable to me. Everyone would likely dogpile onto the leader after a little while.

Pieces to the forking infrastructure still needed/desired: full replay attack protection, PoW change(?), and wallet software that makes it easy for merchants to be paid in all coins at once, or whatever their preferred mix (automatic coordination with Shapeshift would be ideal for speculators) just in case the forkbitrage process lasts more than a few hours, which would affect merchants.

 

[freetrader]

@Zangelbert Bingledack : I would hope that future payment processors would offer interfaces where the customer can be offered the degree of currency mixing freedom that a merchant is willing to accept.

I would like to be able to pay in whatever mix of crypto (counting forks) that I currently want to spend from and have available.

Gimme some slider bars, until I meet the total amount due, and a "Send button".

--

On Meni's article:

I saw he took fast retargeting into account for the oscillation problem, although he presented it a bit later after first describing the problem. But it still covered his argument well enough, that this levels things out from the totally-favors-the-majority situation w/o quick diff adjustment, to a much more optimistic outlook for even asymmetric forks.

His principled stance - I like it. It speaks to one of the most attractive aspects of Bitcoin, as far as I'm concerned. I'm on the same page, but I think this is a marvellous opportunity for economists to design a suitable experiment to test the theory of whether 51% attacks are truly worth it, vs. the honest mining option.

 

[Zarathustra]

@freetrader said:
My point here is not to claim either side is innocent on all counts, far from it.

@jonny1000 answers:
I agree the tactics used on both sides are almost identical.

Agree? That's not what he claims, you unscrupulous writer.

 

[cliff]

Gold Collapsing, Bitcoin UP!

Bitcoin has recovered a bit since dipping below $500 briefly yesterday. Tradeblock’s Index currently shows a price of $566-ish.

Gold is down this morning - ~$1360/oz.

Crude remains under $40/barrel .

Heard here first yesterday (hours before anywhere else - except my twitter), CFTC’s regs and fine against Bitfinex may have played a significant role in yesterday’s hack – Bitfinex was unable to hold margin trader funds in a cold wallet. WSJ has a nice write up.
-----------

Shout out

 

[lunar]

https://www.reddit.com/r/btc/comments/4vx6ci/bw_announcement_about_online_etc_mining_pools_and/

Well, that's good to know. Can't be evil (unless lack of indicators permits).

I wonder how far along they got with the "choice" part of Bitcoin block size. Oh wait, there were agreements in the way. But haven't they expired?

post removed: ..... why?

Quoted here for reference.

BW Announcement About Online ETC Mining Pools And ETC Balance Withdrawal 14:50:00 August 1st, 2016 Dear Users: After hard fork, the old chain of Ethereum does not disappear, but continues to exist in the form of ETC, and with the recognition and online ETC transactions of main trading platforms, ETC now has become a valuable digital asset. Under the support and trust of miners, ETH mining pool of BW(new chain after hard fork) has grown into one of the world's leading ETH mining pools. BW ETH mining pool daily pays the users income in a timely manner, and has upgraded wallet payment hard fork to ensure users run on a longer chain before the hard fork. The users’ ETC balance has been distributed to the user’ account, users can log on the individual center to withdraw ETC. The total distribution is the BW ETH mining pool wallet balance at the time of hard fork, and the ETH mining income at the day of hard fork will be distributed to users according to the proportion. Since Ethereum community has recognized the existence of ETC on his official blog, BW will adhere to the neutral and non-evil attitude and respect the choice and actual demand of miners. After research, BW decides to online ETC mining pool in Beijing time 15:00, August 1,2016 for miners to choose. Mining pool address: bwetc.bw.com Stratum port: 8080 Getwork port: 8008 PPS rate: 2.5% Payment cycle: 00:00 to 24:00, in the morning we will pay the yesterday's gains Minimum payment: 0.1Ether Users set the wallet address must be carried out in https://etc.bw.com/pool Mining fee will be paid by BW from the PPS fee, no need miners to pay. If each payment cycle is less than 0.1 Ether, it can not be paid to the user specified ETC wallet address, but will be paid to the user’s account. If user account balance is more than 0.1Ether, users can withdraw the account balance to the specified address. BW ETH and ETC mine pool does not support anonymous mining, the users must use the wallet address same as mining end in the payment setting of web site. In order to avoid the risk of replay attacks, users do not set the same ETH wallet address as ETC. As the core of ETH is same with ETC, it is difficult to judge the future trend, BW will return the choice right to the miners, and will be more closely pay attention to the trends of Ethereum community in the future to assess the relevant technical programs and ETC mining pool operation. Related information Https://github.com/ethereum/mist/releases Http://ethfans.org/topics/563 ETC official website:Https://ethereumclassic.github.io/ ETC block browser:Http://gastracker.io/ BW www.bw.com August 1, 2016

https://www.bw.com/news/show-94-proclamation

币网上线ETC矿池及ETC余额提取的公告 2016-08-01 14:50:00 尊敬的用户： 以太坊的硬分叉后，旧链并没有消失，而是以ETC的形式继续存在，而随着主要的交易平台承认并上线ETC交易，ETC已经成为有价值的数字货币资产。 币网的ETH（分叉后的新链）矿池在矿工的支持和信赖下，已经成长为全球主要的ETH矿池之一。币网ETH矿池每日及时支付用户收益，在硬分叉之前，已经 升级钱包支付硬分叉，确保用户运行于较长链上。用户的ETC余额已经发放至用户账户，用户可登录前往个人中心提取ETC。分配的总额为硬分叉节点币网 ETH矿池钱包余额，用户依照分叉日获得的ETH挖矿收益按比例分配。 由于以太坊社区已经在官方博客上认同ETC的存在，币网秉承中立、不作恶的态度，尊重矿工的选择权及矿工的实际需求，经公司研究决定，于北京时间2016 年8月1日15:00上线ETC矿池，供矿工朋友选择。 矿池地址：bwetc.bw.com Stratum端口：8080 Getwork端口：8008 PPS费率：2.5% 支付周期：0点到24点，上午支付昨日收益 最小支付：0.1Ether 用户设置钱包地址必须在https://etc.bw.com/pool中进行 矿工费将由币网从PPS费中支付，不需要矿工支付。每个支付周期少于0.1的Ether无法通过自动提币支付到用户指定的ETC钱包地址，将支付到用户账 户。用户账户余额高于0.1Ether时，用户可以发起提币，提取账户余额到指定的钱包地址。 币网的ETH及ETC矿池不支持匿名挖矿，用户必须在网站的付款设置中使用挖矿端同样的钱包地址。为避免重放攻击的风险，用户请勿设置相同的ETH及 ETC钱包地址。 由于ETH及ETC的核心一致，难以评判未来走向，币网将选择权交还矿工，并将在未来更密切留意以太坊社区动态，评估相关技术方案及ETC矿池运行情况。

相关资讯 Mist 0.8.1 切换 ETC 和 ETH https://github.com/ethereum/mist/releases http://ethfans.org/topics/563 ETC官网： https://ethereumclassic.github.io/ ETC区块浏览器： http://gastracker.io/ 社区态度： https://blog.ethereum.org/2016/07/26/onwardfromthehardfork/ http://ethfans.org/posts/agrabbagofthoughtsonetcandforks

币网www.bw.com 2016年8月1日

https://www.bw.com/news/show-94-proclamation

https://r.go1dfish.me/r/btc/comments/4vx6ci/bw_announcement_about_online_etc_mining_pools_and/

has been an invaluable source in these times of censorship