Bitcoin Forum
May 22, 2019, 04:18:19 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 »
1  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: August 26, 2017, 07:59:53 PM
P2Pool release 17.0 - commit hash: 62fa7b020b82a92138d7652c26be2953b26fd4e5

HARDFORK - Upgrade URGENTLY required in the next few days.

Windows binary: http://u.forre.st/u/iqvaqprd/p2pool_win32_17.0.zip
Windows binary signature: http://u.forre.st/u/ysrjpsls/p2pool_win32_17.0.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/17.0
Source tarball: https://github.com/forrestv/p2pool/tarball/17.0

Changes:

* SegWit compatibility
* Increased new transactions size limit per share to allow producing larger blocks
* Requires Bitcoin >= 0.13.1

SegWit (segregated witness) **has already activated** and for P2Pool to continue working without producing invalid blocks, everyone needs to upgrade. At 50% of our hashrate upgrading, P2Pool instances will start displaying a warning saying that an upgrade is required. Reaching that point as quickly as possible is very important. And then, at 95%, users that have not upgraded will be excluded. If non-upgraded users aren't excluded soon enough, P2Pool users will be subject to paying other users for invalid work - effectively a withholding attack.

Due to SegWit already activating upgraded users of P2Pool must not mine SegWit transactions as they are incompatible with older P2Pool versions. After v17 shares activate a new release will be made which removes this restriction.

So, please upgrade to 17.0 now and also tell everyone else to.
2  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: May 12, 2017, 01:49:11 AM
I don't see anything wrong with jtoomim's posts here.

With regard to development efforts, jtoomim: I'll merge any pull requests from you from now on that pass a quick review (I don't have means to test currently). If you want, we can discuss giving you push access to https://github.com/p2pool/p2pool.

ck-'s point about making a new thread may make sense if jtoomim takes over and creates new releases, as he'll be unable to directly edit the first post of this thread that links to them.
3  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: April 14, 2017, 10:39:12 AM
At this point, neither of the valid heads (D2 and E2) are block-stale, so neither one gets punished for that. Ultimately, the one that wins is the one with the most work. Not all shares have the same difficulty. If B1 was higher difficulty than C2, and D2 is equal to E2, then the total work behind D2 will be greater than E2, and E2 will get preferentially orphaned.

Shares are compared using the total work of their 5th parent, rather than their own work (data.py line 836). As a result of that, practically, forks are chosen between based on height with arrival time breaking ties. Difficulty doesn't come into it.

Can you correct that in your post? I think most of your arguments are unaffected.
4  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: April 14, 2017, 07:15:11 AM
Hey, jtoomim. All of what you described (including the edit) are not bugs.

First of all, remember that orphaned shares are not inherently bad. If everyone on P2Pool has the same orphan rate, then everyone's payouts are fair. Now, with that in mind...

Here's an example scenario:
Code:
A1
|  \
B1  C2
(letter is share ID, number is block it refers to)

You noticed that a node will always prefer building off of C2 rather than B1, even if C2 came in way later than B1. I think that most would agree with this policy, on the basis that C2's work is much more useful, since it was entirely on a new block, instead of possibly partially on an old block (and therefore possibly partially useless). You implied that you agree with this, so I won't go any further.

Given that rule, the optimal (selfish) strategy for any node mining is to try to make a share C2 if it doesn't exist yet (assuming B1 isn't theirs), since they will benefit from the pool ignoring share B1. This situation is when the "Punishing share for Block-stale detected!" message is printed.

Doing anything else, as you proposed, would (slightly) disadvantage the people doing it. If the software didn't follow the optimal strategy by default, people would be (slightly) motivated to patch their P2Pool instances to implement the optimal strategy. Right now, every node follows the optimal strategy, and so we're at a Nash equilibrium. Everyone does everything the same, so all is fair, and there's nothing better to do.

Yes, the current strategy results in one share being orphaned per block (the last share that was mined for a given block). However, the current state of things:
  • Is unavoidable, by the argument above
  • Is still fair (just a slight variance increase) if everyone gets the new blocks at the same
  • Punishes people with slow bitcoind instances in a manner that I believe is fair (which is good for the pool, as people with fast bitcoinds aren't paying those with slow bitcoinds for useless work)

Also, note that a node will not try to orphan a share if it has the same payout address as theirs, so running a few nodes with the same payout address won't disadvantage you compared to running a single node.
5  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: March 26, 2017, 05:31:55 PM
As a separate issue, I now realize that current P2Pool doesn't allow *expressing* support for SegWit, due to line 372 in work.py, which veqtrus's changes don't touch:

Code:
version=max(self.current_work.value['version'], 0x20000000),

If anyone can confirm that fixing that is as simple as changing it to

Code:
version=max(self.current_work.value['version'], 0x20000002),

This is wrong. I changed p2pool to signal whatever BIP9 compatible fork a client supports in the CSV commit.

Ah, oops. I misread max as what it used to be (min). Great, so that's not a problem.



How to get out of this situation? Now for my node I use veqtrus patches from the segwit1+empty_block_fix1 branch of a https://github.com/veqtrus/p2pool.git repository.
When my node's  hashrate was raised and the amount of v17 shares was increased above then 50%, the message with a link to  p2pool.in appeared on another nodes. But there is no announcement about a new version. Owners of other nodes will not do anything.
What to do if the main developers can not agree?

sawa, you shouldn't be using the fork right now. The main branch does everything you could want right now (namely, just indicate SegWit support). A majority of P2Pool hashrate using a fork will indeed confuse other miners.
6  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: March 25, 2017, 11:31:53 PM
Hi all. As windpath said, I'm not very active with Bitcoin recently. However, I will continue to merge/develop, test, and release changes necessary to keep P2Pool working with any Bitcoin hardforks.

There's an issue tracking SegWit support in P2Pool here which references veqtrus's awesome work adding SegWit support.

I don't plan to merge/test/release that until it looks like SegWit activation is actually happening, which according to http://segwit.co/, won't be in the near future.



As a separate issue, I now realize that current P2Pool doesn't allow *expressing* support for SegWit, due to line 372 in work.py, which veqtrus's changes don't touch:

Code:
version=max(self.current_work.value['version'], 0x20000000),

If anyone can confirm that fixing that is as simple as changing it to

Code:
version=max(self.current_work.value['version'], 0x20000002),

, then I will publish a new P2Pool release with that change.
7  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: June 20, 2016, 06:04:35 AM
I suppose i'll just dirty up the code a bit . . .

It should run fine with Bitcoin Classic...

EDIT: I don't really know. I assumed Classic would support and indicate that it provides support for the upcoming softforks, but I don't know.
8  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: June 20, 2016, 04:33:20 AM
Which coin daemons are supported this release? Just core 0.12.1+?

For the Bitcoin network, yes. For other P2Pool networks, no requirements were changed.
9  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: June 19, 2016, 09:25:02 PM
P2Pool release 16.0 - commit hash: d3bbd6df33ccedfc15cf941e7ebc6baf49567f97

HARDFORK - Upgrade URGENTLY required in the next few days.

Windows binary: http://u.forre.st/u/wanckfqm/p2pool_win32_16.0.zip
Windows binary signature: http://u.forre.st/u/wqjnuihh/p2pool_win32_16.0.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/16.0
Source tarball: https://github.com/forrestv/p2pool/tarball/16.0

Changes:
* CSV compatibility
* Requires Bitcoin >=0.12.1

Several BIPs will take effect in the next few days and in order for P2Pool to continue working without producing invalid blocks, everyone needs to upgrade. At 50% of our hashrate upgrading, P2Pool instances will start displaying a warning saying that an upgrade is required. Reaching that point as quickly as possible is very important. And then, at 95%, users that have not upgraded will be excluded. If non-upgraded users aren't excluded before the Bitcoin changes takes effect, P2Pool users will be subject to paying other users for invalid work - effectively a withholding attack.

So, please upgrade to 16.0 now and also tell everyone else to.
10  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: April 20, 2016, 05:11:17 PM
Hey squidicuz, I started an issue to track this problem: https://github.com/p2pool/p2pool/issues/305

Can you upload a more complete section of your P2Pool log file? Ideally an hour behind and forward or so?
11  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: April 15, 2016, 03:45:20 AM

When P2Pool learns that there's a new block, it mines empty blocks until bitcoind gives it a block template.

The alternative to doing this would be to mine orphaned blocks rather than empty ones. :/
12  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: December 21, 2015, 12:11:56 AM
If someone appears to have gotten paid, it's just because they still had shares in the sharechain (which is several days long).
13  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: December 20, 2015, 11:26:13 PM
As of a few days ago, outdated miners are excluded from the Bitcoin P2Pool. There's no problem or changes required.
14  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: December 18, 2015, 10:38:11 PM
Here is the error that results from trying to start the pool on litecoin with the following command.

Ah, okay, fixed in git HEAD. You probably should be using a release if you want stability, FYI. (To do that, look at the output of "git tag" and then "git checkout" the latest one.)
15  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: December 18, 2015, 07:18:56 PM
I am getting an error connecting to the blockchain that traces back to something called softforks. It seems unable to connect to the blockchain.

Can you post the error/traceback you're getting from P2Pool?
16  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: December 15, 2015, 09:54:29 AM
yes i have p2pool v 15.0.1, but this work?:

https://github.com/p2pool/p2pool/blob/master/p2pool/work.py

 - version=min(self.current_work.value['version'], 4),
 + version=536870919,

Yes.
17  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: December 15, 2015, 09:18:49 AM
this change http://xtnodes.com/p2pool_configuration.php

work for new v4 ? or need different configuration for xt nodes?


You need to be upgraded to the newest P2Pool version (v15.0, to support v4 blocks/BIP65) and then also make that change (if you want to support Bitcoin XT).
18  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: December 12, 2015, 10:42:07 PM
Hmm, can you apply this[1] patch to P2Pool and post the relevant log sections of both bitcoind and P2Pool?

1: http://im.forre.st/pb/80707844.txt
19  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: December 12, 2015, 10:11:05 PM
P2Pool should immediately call getblocktemplate after it knows that there is a new block. It is notified that there is a new block via its P2P connection to bitcoind, through which bitcoind sents an inv message when it has a new block. The code that does this is the work_poller in node.py. The reason that you saw a 18 second delay is something within that loop. Maybe bitcoind was lagging and took a long time to announce the block after it printed "new best"? Or maybe P2Pool was lagging and took a long time to respond. Is the delay always long or just for this one block?

That said, P2Pool will generate its own work if it knows that there is a new block (via its P2Pool peers) and bitcoind hasn't given it new work yet. These blocks will be empty, though. It's just a stopgap solution for bitcoind sometimes taking a long time to catch up.

In other news, a lot of users (or one big user) upgraded to v15 in the last day, and we'll probably be fine when BIP65 takes effect.
20  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: December 11, 2015, 02:40:10 AM
Hey Forrestv, v0.11D of BitcoinXT is now officially released with support for BIP65: https://github.com/bitcoinxt/bitcoinxt/releases/tag/v0.11D

Okay, can you post the output of the RPC getinfo command?
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!