Bitcoin Forum
May 25, 2018, 11:42:04 AM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 [779] 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2558997 times)
jtoomim
Hero Member
*****
Offline Offline

Activity: 818
Merit: 1001


View Profile WWW
July 19, 2017, 09:42:21 PM
 #15561

I just finished a beta version of a merge of veqtrus's SegWit code with my 1mb_hardforked+lowmem code. I've also added a couple of things that should improve the likelihood of it working with altcoins. I'm testing with Bitcoin right now. I'll try to have the testing done and the Bitcoin code ready for others to use within a couple of days, and then I'll work on the altcoin stuff and test it with Litecoin.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
1527248524
Hero Member
*
Offline Offline

Posts: 1527248524

View Profile Personal Message (Offline)

Ignore
1527248524
Reply with quote  #2

1527248524
Report to moderator
1527248524
Hero Member
*
Offline Offline

Posts: 1527248524

View Profile Personal Message (Offline)

Ignore
1527248524
Reply with quote  #2

1527248524
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1527248524
Hero Member
*
Offline Offline

Posts: 1527248524

View Profile Personal Message (Offline)

Ignore
1527248524
Reply with quote  #2

1527248524
Report to moderator
1527248524
Hero Member
*
Offline Offline

Posts: 1527248524

View Profile Personal Message (Offline)

Ignore
1527248524
Reply with quote  #2

1527248524
Report to moderator
Xantus
Jr. Member
*
Offline Offline

Activity: 43
Merit: 0


View Profile
July 19, 2017, 09:51:13 PM
 #15562

Questions:
Running bitcoin 14.2 with the -addnode=.location.fibre.bitcoinrelaynetwork.org, is this correct? I have been whitelisted.

Running 16.0-4-gde 1be30, is there another version I should be running for BIP 91?

If not then what is the version as I would like to add the BIP 91 nodes as stated above.

If these have been answered can you please provide the links? I have search here and the web and can’t seem to put my finger on it.

my question is nearby,

is there a way to see the aktual sign/bits for bip´s my node / my miner has set ?
And can i change this for my miner or for my p2pool node or is that p2pool wide fixed ? and if yes how can i do that ?

my wich is to support PIB91 (perhaps to late for 91 but i could switch in that case to BIP141)

p.s. hi there ;-)
jtoomim
Hero Member
*****
Offline Offline

Activity: 818
Merit: 1001


View Profile WWW
July 19, 2017, 10:28:44 PM
 #15563

is there a way to see the aktual sign/bits for bip´s my node / my miner has set ?
And can i change this for my miner or for my p2pool node or is that p2pool wide fixed ? and if yes how can i do that ?
Using a web browser, navigate to your node's status page, and click on one of the links in My Shares. Then look for a section that looks like this:

Code:
Header

Version (dec): 536870930

Version (hex): 20000012
(I recently switched my node over to btc1 too.)

The bitcoind version you're using (Unlimited/Core/btc1/etc) will include a version bits suggestion which gets passed to your p2pool node in the getblocktemplate response. Depending on which version of the p2pool code you're using, your p2pool node may either use the version bits it receives from bitcoind, or it may override it (see https://github.com/jtoomim/p2pool/blob/lowmem/p2pool/work.py#L386 for an example -- I've never liked that max() line, but haven't changed it in my branch yet). If you want to force particular version bits even though the bitcoind you're using doesn't make those version bits, you can do so by editing that line in your p2pool source code. Each p2pool node can use different version bits, so the final block version bits that you see depends on which p2pool node actually mined the block.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
windpath
Legendary
*
Offline Offline

Activity: 1233
Merit: 1000


View Profile WWW
July 19, 2017, 11:50:56 PM
 #15564

I just finished a beta version of a merge of veqtrus's SegWit code with my 1mb_hardforked+lowmem code. I've also added a couple of things that should improve the likelihood of it working with altcoins. I'm testing with Bitcoin right now. I'll try to have the testing done and the Bitcoin code ready for others to use within a couple of days, and then I'll work on the altcoin stuff and test it with Litecoin.

Awesome!

veqtrus
Member
**
Offline Offline

Activity: 107
Merit: 10


View Profile WWW
July 20, 2017, 10:25:09 AM
 #15565

I just finished a beta version of a merge of veqtrus's SegWit code with my 1mb_hardforked+lowmem code. I've also added a couple of things that should improve the likelihood of it working with altcoins. I'm testing with Bitcoin right now. I'll try to have the testing done and the Bitcoin code ready for others to use within a couple of days, and then I'll work on the altcoin stuff and test it with Litecoin.

My patch is already running successfully on vertcoin's p2pool. In fact after segwit's activation p2pool's hashrate rose so much that the devs made a second network for smaller miners.

P2Pool donation button | Bitrated user: veqtrus.
TierNolan
Legendary
*
Offline Offline

Activity: 1176
Merit: 1001


View Profile
July 20, 2017, 12:08:48 PM
 #15566

Each p2pool node can use different version bits, so the final block version bits that you see depends on which p2pool node actually mined the block.

Are you planning to enforce BIP-91 for p2pool (assuming it locks in)?

If someone produces a share without the segwit bit set, then that share is effectively worthless (at least until segwit is locked in).

An easy rule would be that the bit must be set until August 1st and then while at least 750 of the last 1000 blocks have it set.  That saves you needing to add code to figure out if segwit has been locked in.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
jtoomim
Hero Member
*****
Offline Offline

Activity: 818
Merit: 1001


View Profile WWW
July 20, 2017, 01:06:14 PM
 #15567

Are you planning to enforce BIP-91 for p2pool (assuming it locks in)?
This is a complicated question. Currently, there's an incompatibility between p2pool and BIP91 in that p2pool will mine a transaction-free block on top of the longest chain seen if p2pool hears about a new block but bitcoind does not inform p2pool about this block. While I think this is the correct behavior during normal operation, it is clearly incorrect behavior during chainsplit conditions, so it will need to be disabled for the next month or so. I will be including that change in the new branch I'm working on that merges SegWit and large block generation capability.

Quote
If someone produces a share without the segwit bit set, then that share is effectively worthless (at least until segwit is locked in).
I am not convinced that this is the correct action to take. P2pool generally does not validate the blocks that other nodes are trying to mine except to ensure that the payouts are fair. I'm not sure that we should start now. On one hand, it serves as an added incentive for people to ensure that they are BIP91 compatible. On the other hand, it disincentivizes miners using p2pool as a tool to vote their conscience. I tend to believe that the latter objective is generally more important, but I'm not sure in this particular case. It may be that people would want to exploit p2pool to mine minority-chain blocks while still getting paid on the majority chain, which could be a problem. Perhaps the best solution is just to fork the share chain again, and let anyone who wants to disobey BIP91 do so on their own minority sharechain. However, that approach would require the most work of any.

Quote
An easy rule would be that the bit must be set until August 1st and then while at least 750 of the last 1000 blocks have it set.  That saves you needing to add code to figure out if segwit has been locked in.
That would actually be a difficult rule, since p2pool does not store a copy of the blockchain anywhere, and is unable to evaluate whether 750 of the last 1000 blocks have it set.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
TierNolan
Legendary
*
Offline Offline

Activity: 1176
Merit: 1001


View Profile
July 20, 2017, 01:47:38 PM
 #15568

While I think this is the correct behavior during normal operation, it is clearly incorrect behavior during chainsplit conditions,

If BIP-91 goes into effect, then BTC1 connectivity is going to be an issue, agreed.

Even nodes with the btc1 client aren't safe, since they could be surrounded by non-BIP-91 nodes and not get the updated block (since it counts as a tie).

Quote
so it will need to be disabled for the next month or so. I will be including that change in the new branch I'm working on that merges SegWit and large block generation capability.

How will that work?  You can't build non-empty blocks if your local bitcoin node doesn't have the tip block. 

You could poll the local node.  If it has it, then it might send it even if it isn't the longest chain (as far as it is concerned).

I think BIP-91 nodes will preferentially connect to at least a few BIP-91 other nodes (or maybe they didn't bother with that).  That means that if the local node is btc1, then you would be ok.

Quote
I am not convinced that this is the correct action to take. P2pool generally does not validate the blocks that other nodes are trying to mine except to ensure that the payouts are fair.

That is because p2pool cannot verify without lots of overhead (distribute the full block for each share).

If BIP-91 locks in, then it is guaranteed that blocks which don't flag segwit are invalid and that info is in the header which (I assume) is shared between p2pool nodes.

Quote
I'm not sure that we should start now

It would definitely be an emergency fix and has a risk/reward profile.  Network-wise, it is a soft fork.

Quote
On one hand, it serves as an added incentive for people to ensure that they are BIP91 compatible.

Shares which are invalid are basically draining the network of earning potential.  They get paid, but provide nothing.

Quote
On the other hand, it disincentivizes miners using p2pool as a tool to vote their conscience.

I am not suggesting that you should force people to vote for BIP-91.

However, if BIP-91 does lock in, then that counts as a soft fork and a change to the bitcoin rules.

You would be enforcing the (new/soft forked) Bitcoin protocol. 

Quote
Perhaps the best solution is just to fork the share chain again, and let anyone who wants to disobey BIP91 do so on their own minority sharechain. However, that approach would require the most work of any.

You could soft fork it.  If 75% agree, then activate the change.  As you say, it is a judgement call.  Maybe people would like to preserve the ability to create their own blocks.

Quote
That would actually be a difficult rule, since p2pool does not store a copy of the blockchain anywhere, and is unable to evaluate whether 750 of the last 1000 blocks have it set.

Fair enough.  You could just make it time based (all blocks from now until 15 August).

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
jtoomim
Hero Member
*****
Offline Offline

Activity: 818
Merit: 1001


View Profile WWW
July 20, 2017, 06:28:31 PM
 #15569

The point I was trying to make is that btc1 and other BIP91 clients will blacklist certain blocks, and the current version of p2pool will ignore and violate that blacklisting. This needs to be fixed. P2pool should not assume that blocks that it hears about over the network and not via bitcoind are valid when chainsplits are occurring.

Basically, the tip that p2pool sees will often be the wrong tip. P2pool needs to trust its bitcoind for the next month.

Making sure that btc1/bitcoind always has the best block is a separate issue. All btc1 miners need to ensure that they have used addnode or one of Matt Corallo's relay networks to connect to other btc1 miners, but that is not something that p2pool can control.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
windpath
Legendary
*
Offline Offline

Activity: 1233
Merit: 1000


View Profile WWW
July 20, 2017, 07:45:04 PM
 #15570

BIP91 clients will blacklist certain blocks, and the current version of p2pool will ignore and violate that blacklisting

Since we are forking anyway would it not be cleaner for p2pool to do a simple version check on blocks it receives from other p2pool nodes, or would further validation be required?

TierNolan
Legendary
*
Offline Offline

Activity: 1176
Merit: 1001


View Profile
July 20, 2017, 07:59:09 PM
 #15571

The point I was trying to make is that btc1 and other BIP91 clients will blacklist certain blocks, and the current version of p2pool will ignore and violate that blacklisting. This needs to be fixed. P2pool should not assume that blocks that it hears about over the network and not via bitcoind are valid when chainsplits are occurring.

I guess it is an inherent part of p2pool that you trust the other miners aren't throwing their hashing power away.

Quote
Basically, the tip that p2pool sees will often be the wrong tip. P2pool needs to trust its bitcoind for the next month.

Well if bitcoind is core, then it is "wrong" since it is not checking the new soft-forking rule.

No matter what side someone is on the debate, miners need to update to the latest locked-in soft fork or they can lose money.

Assuming that 20% of the mining power is not segwit2x compatible, then for about 1 in 5 blocks, non-btc1 clients will be on an invalid tip.

If only 50% of p2pool miners are updated, then that represents a pool efficiency drop of around 10%.

What will likely happen is that most miners will quickly become compatible, if 95% of miners are compatible, then only 1 in 20 blocks will have a problem.  That means that the efficiency cost (assuming 50% updated) is only a 2.5% and is probably not worth the hassle.

I think producing empty blocks if the node is trying to build on a non-BIP91 chain is reasonable and would virtually eliminate the efficiency cost (but mean no transactions).

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2534
Merit: 1072


Ruu \o/


View Profile WWW
July 20, 2017, 08:52:18 PM
 #15572

A lot of this discussion may be a non-event now. Since the BIP91 support is overwhelming now, the chance of the network being partitioned is getting smaller by the minute. Very shortly even those pools that haven't been supporting BIP91 will reluctantly convert to the code to avoid having their blocks being orphaned. In which case there really will only be segwit compatible blocks generated once BIP91 being activated except for some very small minority miners that may not have updated. If p2pool runs BIP141 segwit compatible that will likely be enough to avoid building on a dead end chain because it looks like there won't be any dead end chain...

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
jtoomim
Hero Member
*****
Offline Offline

Activity: 818
Merit: 1001


View Profile WWW
July 20, 2017, 11:36:52 PM
 #15573

Since we are forking anyway would it not be cleaner for p2pool to do a simple version check on blocks it receives from other p2pool nodes, or would further validation be required?
It's not a simple version check for p2pool, unfortunately, because the duration of the version check is very specific, and it requires a copy of the blockchain (which p2pool does not have) in order to know what that duration is.

-ck, the question is whether p2pool should allow BIP91-incompatible shares, not blocks. I'm fine with people mining BIP91-incompatible blocks if they want to, but it's not clear that they should get rewarded by other p2poolers for their folly.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
TierNolan
Legendary
*
Offline Offline

Activity: 1176
Merit: 1001


View Profile
July 21, 2017, 11:36:19 AM
 #15574

If p2pool runs BIP141 segwit compatible that will likely be enough to avoid building on a dead end chain because it looks like there won't be any dead end chain...

Ironically, the problem is that bitcoin-core doesn't reject blocks that don't flag segwit.  That means that p2pool miners who are using core will build on the wrong block whenever a non-segwit block is found.

If p2pool built empty blocks when bitcoind is building on a non-segwit block, then almost all the inefficiency goes away.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2534
Merit: 1072


Ruu \o/


View Profile WWW
July 21, 2017, 10:17:45 PM
 #15575

If p2pool runs BIP141 segwit compatible that will likely be enough to avoid building on a dead end chain because it looks like there won't be any dead end chain...

Ironically, the problem is that bitcoin-core doesn't reject blocks that don't flag segwit.  That means that p2pool miners who are using core will build on the wrong block whenever a non-segwit block is found.

If p2pool built empty blocks when bitcoind is building on a non-segwit block, then almost all the inefficiency goes away.
The thing is there is virtually no one left mining non-BIP91 (connectbtc and any solo miners out there who haven't changed as far as I can see) so you'd have to be ultra-unlucky to build on one block in 100 that isn't signalling segwit AND find a block. Possible, yes, but extremely unlikely. I think anyone left will probably change to signal segwit anyway before then.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
TierNolan
Legendary
*
Offline Offline

Activity: 1176
Merit: 1001


View Profile
July 21, 2017, 10:31:08 PM
 #15576

The thing is there is virtually no one left mining non-BIP91

Xbt is showing SW + BIP91 = 99.3% so agreed the point is moot anyway.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
kano
Legendary
*
Offline Offline

Activity: 2464
Merit: 1042


Linux since 1997 RedHat 4


View Profile
July 21, 2017, 11:37:27 PM
 #15577

The thing is there is virtually no one left mining non-BIP91

Xbt is showing SW + BIP91 = 99.3% so agreed the point is moot anyway.
Moot? No. It's not zero. Not likely, is not zero.

When you next find a block, if it's rejected because p2pool 'will' mine on invalid blocks, you know it's because no one fixed it.
Damn shame.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
TierNolan
Legendary
*
Offline Offline

Activity: 1176
Merit: 1001


View Profile
July 22, 2017, 09:10:10 AM
 #15578

When you next find a block, if it's rejected because p2pool 'will' mine on invalid blocks, you know it's because no one fixed it.
Damn shame.

Now that I think about it more, there are actually 3 percentages that matter.

1) Total miners who are signalling segwit (that is around 99.3%)
2) P2pool miners who are not signaling segwit
3) P2pool miners who are using non-BIP-91 compatible code

The cost of 3) depends on the 1).  If almost all blocks signal segwit then the fact that sometimes p2pool miners build on the wrong block doesn't have much effect.

2) is a direct cost.  If 80% of p2pool miners are flagging segwit, then 20% of the blocks that p2pool finds will be invalid.  In that case, mining on p2pool is like mining on a pool that has 20% fees (except that nobody actually gets the fees).

A rule that that marks shares that don't flag segwit as invalid would be justified.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Xantus
Jr. Member
*
Offline Offline

Activity: 43
Merit: 0


View Profile
July 22, 2017, 10:26:18 AM
 #15579

why p2pool Miner dont set the segwit2x bit ?
Meuh6879
Legendary
*
Offline Offline

Activity: 1512
Merit: 1000



View Profile
July 22, 2017, 12:09:35 PM
 #15580

BIP9 signaling (more than 95%) : http://bitcoin.sipa.be/versions.html





https://www.xbt.eu/ (144 Blocks)
Pages: « 1 ... 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 [779] 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 »
  Print  
 
Jump to:  

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!