Reference python implementation of Chia pool operations for pool operators

Chia Network

Last update: Dec 13, 2022

Related tags

Miscellaneous blockchain pool cryptocurrency pooling chia chialisp

Overview

Pool Reference V1

This code is provided under the Apache 2.0 license. Note: the draft specification is in the SPECIFICATION.md file.

Summary

This repository provides a sample server written in python, which is meant to server as a basis for a Chia Pool. While this is a fully functional implementation, it requires some work in scalability and security to run in production. An FAQ is provided here: https://github.com/Chia-Network/chia-blockchain/wiki/Pooling-FAQ

Customizing

Several things are customizable in this pool reference. This includes:

How long the timeout is for leaving the pool
How difficulty adjustment happens
Fees to take, and how much to pay in blockchain fees
How farmers' points are counted when paying (PPS, PPLNS, etc)
How farmers receive payouts (XCH, BTC, ETH, etc), and how often
What store (DB) is used - by default it's an SQLite db. Users can use their own store implementations, based on AbstractPoolStore, by supplying them to pool_server.start_pool_server

However, some things cannot be changed. These are described in SPECIFICATION.md, and mostly relate to validation, protocol, and the singleton format for smart coins.

Pool Protocol Benefits

The Chia pool protocol has been designed for security, and decentralization, not relying on any 3rd party, closed code, or trusted behaviour.

The farmer can never steal from the pool by double farming
The farmer does not need collateral to join a pool, they only need a few cents to create a singleton
The farmer can easily and securely change pools if they want to
The farmer can run a full node (increasing decentralization)
The farmer can log into another computer with only the 24 words, and the pooling configuration is detected, without requiring a central server

Pool Protocol Summary

When not pooling, farmers receive signage points from full nodes every 9 seconds, and send these signage points to the harvester. Each signage point is sent along with the sub_slot_iters and difficulty, two network-wide parameters which are adjusted every day (4608 blocks). The sub_slot_iters is the number of VDF iterations performed in 10 minutes for the fastest VDF in the network. This increases if the fastest timelord's speed increases. The dififculty is similiarly affected by timelord speed (it goes up when timelord speed increases, since blocks come faster), but it's also affected by the total amount of space in the network. These two parameters determine how difficult it is to "win" a block and find a proof.

Since only about 1 farmer wordwide finds a proof every 18.75 seconds, this means the chances of finding one are extremely small, with the default difficulty and sub_slot_iters. For pooling, what we do is we increase the sub_slot_iters to a constant, but very high number: 37600000000, and then we decrease the difficulty to an artificially lower one, so that proofs can be found more frequently.

The farmer communicates with one or several pools through an HTTPS protocol, and sets their own local difficulty for each pool. Then, when sending signage points to the harvester, the pool difficulty and sub_slot_iters are used. This means that the farmer can find proofs very often, perhaps every 10 minutes, even for small farmers. These proofs, however, are not sent to the full node to create a block. They are instead only sent to the pool. This means that the other full nodes in the network do not have to see and validate everyone else's proofs, and the network can scale to millions of farmers with no issue, as long as the pool scales properly. Since many farmers are part of the pool, only 1 farmer needs to win a block, for the entire pool to be rewarded proportionally to their space.

The pool then keeps track of how many proofs (partials) each farmer sends, weighing them by difficulty. Occasionally (for example every 3 days), the pool can perform a payout to farmers based on how many partials they submitted. Farmers with more space, and thus more points, will get linearly more rewards.

Instead of farmers using a pool_public_key when plotting, they now use a puzzle hash, referred to as the p2_singleton_puzzle_hash, also known as the pool_contract_address. These values go into the plot itself, and cannot be changed after creating the plot, since they are hashed into the plot_id. The pool contract address is the address of a chialisp contract called a singleton. The farmer must first create a singleton on the blockchain, which stores the pool information of the pool that that singleton is assigned to. When making a plot, the address of that singleton is used, and therefore that plot is tied to that singleton forever. When a block is found by the farmer, the pool portion of the block rewards (7/8, or 1.75XCH) go into the singleton, and when claimed, go directly to the pool's target address.

The farmer can also configure their payout instructions, so that the pool knows where to send the occasional rewards to.

Receiving partials

A partial is a proof of space with some additional metadata and authentication info from the farmer, which meets certain minimum difficulty requirements. Partials must be real proofs of space responding to blockchain signage points, and they must be submitted within the blockchain time window (28 seconds after the signage point).

The pool server works by receiving partials from the users, validating that they are correct and correspond to a valid signage point on the blockchain, and then adding them to a queue. A few minutes later, the pool pulls from the queue, and checks that the signage point for that partial is still in the blockchain. If everything is good, the partial is counted as valid, and the points are added for that farmer.

Collecting pool rewards

The pool periodically searches the blockchain for new pool rewards (1.75 XCH) that go to the various p2_singleton_puzzle_hashes of each of the farmers. These coins are locked, and can only be spent if they are spent along with the singleton that they correspond to. The singleton is also locked to a target_puzzle_hash, which in this diagram is the red pool address. Anyone can spend the singleton and the p2_singleton_puzzle_hash coin, as long as it's a block reward, and all the conditions are met. Some of these conditions require that the singleton always create exactly 1 new child singleton with the same launcher id, and that the coinbase funds are sent to the target_puzzle_hash.

Calculating farmer rewards

Periodically (for example once a day), the pool executes the code in create_payment_loop. This first sums up all the confirmed funds in the pool that have a certain number of confirmations.

Then, the pool divides the total amount by the points of all pool members, to obtain the mojo_per_point (minus the pool fee and the blockchain fee). A new coin gets created for each pool member (and for the pool), and the payments are added to the pending_payments list. Note that since blocks have a maximum size, we have to limit the size of each transaction. There is a configurable parameter: max_additions_per_transaction. After adding the payments to the pending list, the pool members' points are all reset to zero. This logic can be customized.

1/8 vs 7/8

Note that the coinbase rewards in Chia are divided into two coins: the farmer coin and the pool coin. The farmer coin (1/8) only goes to the puzzle hash signed by the farmer private key, while the pool coin (7/8) goes to the pool. The user transaction fees on the blockchain are included in the farmer coin as well. This split of 7/8 1/8 exists to prevent attacks where one pool tries to destroy another by farming partials, but never submitting winning blocks.

##% Difficulty The difficulty allows the pool operator to control how many partials per day they are receiving from each farmer. The difficulty can be adjusted separately for each farmer. A reasonable target would be 300 partials per day, to ensure frequent feedback to the farmer, and low variability. A difficulty of 1 results in approximately 10 partials per day per k32 plot. This is the minimum difficulty that the V1 of the protocol supports is 1. However, a pool may set a higher minimum difficulty for efficiency. When calculating whether a proof is high quality enough for being awarded points, the pool should use sub_slot_iters=37600000000. If the farmer submits a proof that is not good enough for the current difficulty, the pool should respond by setting the current_difficulty in the response.

Points

X points are awarded for submitting a partial with difficulty X, which means that points scale linearly with difficulty. For example, 100 TiB of space should yield approximately 10,000 points per day, whether the difficulty is set to 100 or 200. It should not matter what difficulty is set for a farmer, as long as they are consistently submitting partials. The specification does not require pools to pay out proportionally by points, but the payout scheme should be clear to farmers, and points should be acknowledged and accumulated points returned in the response.

Difficulty adjustment algorithm

This is a simple difficulty adjustment algorithm executed by the pool. The pool can also improve this or change it however they wish. The farmer can provide their own suggested_difficulty, and the pool can decide whether or not to update that farmer's difficulty. Be careful to only accept the latest authentication_public_key when setting difficulty or pool payout info. The initial reference client and pool do not use the suggested_difficulty.

Obtain the last successful partial for this launcher id
If > 3 hours, divide difficulty by 5
If > 45 minutes < 6 hours, divide difficulty by 1.5
If < 45 minutes:
- If have < 300 partials at this difficulty, maintain same difficulty
- Else, multiply the difficulty by (24 * 3600 / (time taken for 300 partials))

The 6 hours is used to handle rare cases where a farmer's storage drops dramatically. The 45 minutes is similar, but for less extreme cases. Finally, the last case of < 45 minutes should properly handle users with increasing space, or slightly decreasing space. This targets 300 partials per day, but different numbers can be used based on performance and user preference.

Making payments

Note that the payout info is provided with each partial. The user can choose where rewards are paid out to, and this does not have to be an XCH address. The pool should ONLY update the payout info for successful partials with the latest seen authentication key for that launcher_id.

Install and run (Testnet)

To run a pool, you must use this along with the main branch of chia-blockchain.

Checkout the main branch of chia-blockchain, and install it. Checkout this repo in another directory next to (not inside) chia-blockchain.
If you want to connect to testnet, use export CHIA_ROOT=~/.chia/testnet9, or whichever testnet you want to join, and run chia configure -t true. You can also directly use the pools.testnet9 branch, although this branch will be removed in the future (or past).
Create three keys, one which will be used for the block rewards from the blockchain, one to receive the pool fee that is kept by the pool, and the third to be a wallet that acts as a test user.
Change the wallet_fingerprint and wallet_id in the config.yaml config file, using the information from the first key you created in step 2. These can be obtained by doing chia wallet show.
Do chia keys show and get the first address for each of the keys created in step 2. Put these into the config.yaml config file in default_target_address and pool_fee_address respectively.
Change the pool_url in config.yaml to point to your external ip or hostname. This must match exactly with what the user enters into their UI or CLI, and must start with https://.
Start the node using chia start farmer, and log in to a different key (not the two keys created for the pool). This will be referred to as the farmer's key here. Sync up your wallet on testnet for the farmer key. You can log in to a key by running chia wallet show and then choosing each wallet in turn, to make them start syncing.
Create a venv (different from chia-blockchain) and start the pool server using the following commands:

cd pool-reference
python3 -m venv ./venv
source ./venv/bin/activate
pip install ../chia-blockchain/ 
sudo CHIA_ROOT="/your/home/dir/.chia/testnet9" ./venv/bin/python -m pool

You should see something like this when starting, but no errors:

INFO:root:Logging in: {'fingerprint': 2164248527, 'success': True}
INFO:root:Obtaining balance: {'confirmed_wallet_balance': 0, 'max_send_amount': 0, 'pending_change': 0, 'pending_coin_removal_count': 0, 'spendable_balance': 0, 'unconfirmed_wallet_balance': 0, 'unspent_coin_count': 0, 'wallet_id': 1}

Create a pool nft (on the farmer key) by doing chia plotnft create -s pool -u https://127.0.0.1:80, or whatever host:port you want to use for your pool. Approve it and wait for transaction confirmation. This url must match exactly with what the pool uses.
Do chia plotnft show to ensure that your plotnft is created. Now start making some plots for this pool nft. You can make plots by specifying the -c argument in chia plots create. Make sure to not use the -p argument. The value you should use for -c is the P2 singleton address from chia plotnft show output. You can start with small k25 plots and see if partials are submitted from the farmer to the pool server. The output will be the following in the pool if everything is working:

INFO:root:Returning {'new_difficulty': 1963211364}, time: 0.017535686492919922 singleton: 0x1f8dab79a614a82f9834c8f395f5fe195ae020807169b71a10218b9788a7a573

Please send a message to @sorgente711 on keybase if you have questions about the 9 steps explained above. All other questions should be send to the #pools channel in keybase.

Comments

add mariadb store and store adjustment through config.yaml

@ppolewicz Convinced me to make this pull request I didn't want to over complicate it so i simply stripped out my personal pool code and added what was needed and only what was needed to use the store.

opened by jack60612 15
It's to easy to cheat as a pool admin...
Hi,

If you see this api, three things are used to cheat on netstat/ partial / point.

Netstat

Solo plot = add partial & points

It was easy to add some solo plot farmer to make the real netspace grow up quickly. Just change pool reward from the chia gui/console and the farmer will get 0.25 , and send 1.75 to the pool wallet. To make it count as plot nft we did it like that.

api route to add solo plot point api handler to calculate it

As you can see, that was pretty easy to cheat on point & partial. and that was completely transparent from chia and the pool.

At the beginning the idea was to encourage people to stay on chia, and take their solo plot until they replot. it went to something else, lead by the administrator.

The call was made each 15 minutes, it’s pretty easy of you harvest this endpoint, to see which partial is fake and not

The difficulty was messed up with that. so if you see leader board, there is no difficulty displayed, like that, nobody can see it.

Just checkout at the pool reward adress and this one i don’t know who is behind it, but it’s related to the pool and solo plotting. You can see the 0,25 farmer reward and the 1,75 who go into the pool, and come back to the farmer.

This reward address is not related to any launcher_id of the pool… Here you can find the endpoint for all farmer

We need tracking & clarity.

With both example above, you can see that it’s pretty easy to cheat on chia-pool, mainly because of thoses two points.

Some critical security points is only at the sight of admin, and people on the pool cannot see it. We need to improve the ability of a pool member to check that the pool protocol is not ripped.

Netspace calcul should be included by chia-pool-protocol, to ensure that a launcher_id cannot cheat on the size.

if it was possible to add solo plot like that, partial & point, it was totally possible to create a fake user with many point & partial. I was not able to be on the server, locked by admin (security was call) so i wasn’t able to see what my api was used for…

~Hope this post could help Chia.~
opened by nymkappa 14
{"error_code":10,"error_message":"Farmer with launcher_id 0xfed8bf943a121bd251d4828c9ea4678c35afe92eb240eb91e71a8f5cea166e08 unknown."}

when i want to use Pool Login Link it shows this message: {"error_code":10,"error_message":"Farmer with launcher_id 0xfed8bf943a121bd251d4828c9ea4678c35afe92eb240eb91e71a8f5cea166e08 unknown."} also i cant see my dashboard in pool.space. however i have 3 plot for about 2 days with the new pool protocol there is no detail for my luncher id : Unable to find details for this farm in Space Pool. If a farmer recently started submitting partials for this farm successfully, it can take a few mins to start seeing details.

opened by mansourlotfi 12
Warning genesis coin not found

Hello, I have a warning that keeps coming back in the pool logs.

2021-07-09T11:12:31.065 pool root : WARNING Can not find genesis coin fcf24cb4c229b9700

Does anyone have an idea what this is about?

opened by FarmingHard 12
distributed architecture and preparation for higher load pt. 2

Hey,

In relation to https://github.com/Chia-Network/pool-reference/issues/91 we would now like to introduce the possibility to start the pool-reference server in multiple instances (probably behind a reverse proxy). In order to achieve that, several looped tasks would have to be factored out from the Pool class, namely: create_payment_loop submit_payment_loop collect_pool_rewards_loop The reason for that is that multiple instances would inevitably try to "spend the same coin". And while they would not succeed, at least eventually, this would cause a lot of unnecessary CPU usage and warning logs. The loops mentioned above would be moved to a class named PaymentManager. An instance of PaymentManager would be supplied at PoolServer creation, with the implementation functionally identical to the current one serving as default. (this is very similar to the changes I introduced in https://github.com/Chia-Network/pool-reference/pull/99)

The Idea we have in mind is that we would like to start N PoolServer instances and just one PaymentManager doing all the cron-like work (the N instances and the separate PaymentManager would use the same database).

My question is: would a PR introducing such refactor be welcome?

opened by mpnowacki-reef 11
pool_escaping_innerpuz.clvm.hex not found ... when starting pool_server.py since the update of branch pools.2021-june-4

Not sure if this is a bug or the fact that i screw up de update.

Should i do a fresh install? of both? revert? (chia-blockchain & pool-reference) If it is a bug, where can i find the instruction fill a proper bug report? Thanks in adavance

I have followed the update process from https://github.com/Chia-Network/chia-blockchain/wiki/INSTALL#ubuntudebian on the chia-blockchain repo and then did the step #7 on the pool refrence side https://github.com/Chia-Network/pool-reference#install-and-run-testnet and when i run sudo CHIA_ROOT="/home/user/chia-pools/.chia/testnet7" ./venv/bin/python pool/pool_server.py i get :

Traceback (most recent call last): File "pool/pool_server.py", line 21, in from pool import Pool File "/home/user/pool-reference/pool/pool.py", line 30, in from singleton import create_absorb_transaction File "/home/user/pool-reference/pool/singleton.py", line 20, in POOL_ESCAPING_MOD = load_clvm("pool_escaping_innerpuz.clvm") File "/home/user/pool-reference/venv/lib/python3.8/site-packages/chia/wallet/puzzles/load_clvm.py", line 37, in load_clvm return Program.from_bytes(bytes(load_serialized_clvm(clvm_filename, package_or_requirement=name))) File "/home/user/pool-reference/venv/lib/python3.8/site-packages/chia/wallet/puzzles/load_clvm.py", line 31, in load_serialized_clvm clvm_hex = pkg_resources.resource_string(package_or_requirement, hex_filename).decode("utf8") File "/home/lltuserpool-reference/venv/lib/python3.8/site-packages/pkg_resources/init.py", line 1156, in resource_string return get_provider(package_or_requirement).get_resource_string( File "/home/user/pool-reference/venv/lib/python3.8/site-packages/pkg_resources/init.py", line 1401, in get_resource_string return self._get(self._fn(self.module_path, resource_name)) File "/home/user/pool-reference/venv/lib/python3.8/site-packages/pkg_resources/init.py", line 1616, in _get with open(path, 'rb') as stream: FileNotFoundError: [Errno 2] No such file or directory: '/home/user/pool-reference/venv/lib/python3.8/site-packages/chia/wallet/puzzles/pool_escaping_innerpuz.clvm.hex'

opened by LouisLoudogTrottier 10
`chia plotnft show `Connection error

venv) [root@c7-zfs chia-blockchain]# chia plotnft show Connection error. Check if the wallet is running at 9256. You can run the wallet via: chia start wallet

(venv) [root@c7-zfs chia-blockchain]# curl --insecure --cert /root/chia-blockchain/.chia/testnet7/config/ssl/wallet/private_wallet.crt \

--key /root/chia-blockchain/.chia/testnet7/config/ssl/wallet/private_wallet.key -d '{"wallet_id": 1}'
-H "Content-Type: application/json" -X POST https://localhost:9256/get_wallet_balance | python -m json.tool % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 258 100 242 100 16 1142 75 --:--:-- --:--:-- --:--:-- 1146 { "success": true, "wallet_balance": { "confirmed_wallet_balance": 0, "max_send_amount": 0, "pending_change": 0, "pending_coin_removal_count": 0, "spendable_balance": 0, "unconfirmed_wallet_balance": 0, "unspent_coin_count": 0, "wallet_id": 1 } }

opened by coinsccg 9
Farmer coin is missing

Hey I tested pool with a single farmer, and my farmer had mined two blocks but both of them did not claim farmer coin(0.25 txch). But pool claimed pool coin and distributed it to farmer

opened by neal-zhu 7

ERROR: Can't select amount higher than our spendable balance (double spend when >1 Claimable amount)

Pool payout creates double spend when >1 Claimable amount is collected.. see log below

first payout accounts for both
payout tries to send the same payouts again

INFO:root:Scanning for block rewards from 1000 to 178298. Found: 2
INFO:root:Claimable amount: 3.5
INFO:root:Not claimable amount: 0.0
INFO:root:Not buried amounts: 0.0
INFO:root:Submitted transaction successfully: 096ca00bc761d4351c7404f9e443a415731387fe7550fd45f8173f27cad718a7

INFO:root:Starting to create payment
INFO:root:Total amount claimed: 3.5
INFO:root:Pool coin amount (includes blockchain fee) 0.035
INFO:root:Total amount to distribute: 3.465
INFO:root:Paying out 355 mojo / point
INFO:root:Will make payments: [{'puzzle_hash': <bytes32: 0c9e8b32539ec4559c81dd272a4a29f608cd96641a4acc0f7dd9debecd2b4905>, 'amount': 35000000000}, {'puzzle_hash': <bytes32: c50cd93bf87bc50604a8c6ba4ffc7c74f8ad123e8ae92d2f928417d769c2b17c>, 'amount': 3005670955185}, {'puzzle_hash': <bytes32: 4e5c713d2dc9daad94af550aeb6cd56c471d62f05801ee5f719f76a1a86441a2>, 'amount': 453497893880}, {'puzzle_hash': <bytes32: 537de8b8a1a78e1512862c800db1ad367a1a63f2f991946174222a2a6ddd76c0>, 'amount': 10203765}]
INFO:root:Submitting a payment: [{'puzzle_hash': <bytes32: 0c9e8b32539ec4559c81dd272a4a29f608cd96641a4acc0f7dd9debecd2b4905>, 'amount': 35000000000}, {'puzzle_hash': <bytes32: c50cd93bf87bc50604a8c6ba4ffc7c74f8ad123e8ae92d2f928417d769c2b17c>, 'amount': 3005670955185}, {'puzzle_hash': <bytes32: 4e5c713d2dc9daad94af550aeb6cd56c471d62f05801ee5f719f76a1a86441a2>, 'amount': 453497893880}, {'puzzle_hash': <bytes32: 537de8b8a1a78e1512862c800db1ad367a1a63f2f991946174222a2a6ddd76c0>, 'amount': 10203765}]
INFO:root:Transaction: {'additions': [{'amount': 3005670955185,
                'parent_coin_info': '0x849c2cd8fd0b444d9eae5c652c26bd0206414a5217fb1257410ce712539ced86',
                'puzzle_hash': '0xc50cd93bf87bc50604a8c6ba4ffc7c74f8ad123e8ae92d2f928417d769c2b17c'},
               {'amount': 453497893880,
                'parent_coin_info': '0x849c2cd8fd0b444d9eae5c652c26bd0206414a5217fb1257410ce712539ced86',
                'puzzle_hash': '0x4e5c713d2dc9daad94af550aeb6cd56c471d62f05801ee5f719f76a1a86441a2'},
               {'amount': 10203765,
                'parent_coin_info': '0x849c2cd8fd0b444d9eae5c652c26bd0206414a5217fb1257410ce712539ced86',
                'puzzle_hash': '0x537de8b8a1a78e1512862c800db1ad367a1a63f2f991946174222a2a6ddd76c0'},
               {'amount': 35000000000,
                'parent_coin_info': '0x849c2cd8fd0b444d9eae5c652c26bd0206414a5217fb1257410ce712539ced86',
                'puzzle_hash': '0x0c9e8b32539ec4559c81dd272a4a29f608cd96641a4acc0f7dd9debecd2b4905'},
               {'amount': 5820947170,
                'parent_coin_info': '0x849c2cd8fd0b444d9eae5c652c26bd0206414a5217fb1257410ce712539ced86',
                'puzzle_hash': '0x41533475e97f5a526cf85185226b008fb73fe8e4e005302f9ab6c317eef22ab5'}],
 'amount': 3494179052830,
 'confirmed': False,
 'confirmed_at_height': 0,
 'created_at_time': 1623340190,
 'fee_amount': 0,
 'name': '0x7f4df74785255d88278313647403b842f503cf27fa8a883b1ae186a0b7ee1cc0',
 'removals': [{'amount': 1750000000000,
               'parent_coin_info': '0xe0238891f563c0b04190f98aa3ca462304e9f1066d4be01c417d07a7994e8197',
               'puzzle_hash': '0x38737d10729bb92f459a2000545eb849d1694ae83e357e801f5cfbed6fd24a90'},
              {'amount': 1750000000000,
               'parent_coin_info': '0xf30448c44f979fbb5659288b7bb7ae04f7778e924be9efa063b38ff497594879',
               'puzzle_hash': '0x38737d10729bb92f459a2000545eb849d1694ae83e357e801f5cfbed6fd24a90'}],
 'sent': 0,
 'sent_to': [],
 'spend_bundle': {'aggregated_signature': '0xb2f60be5deb01f29f93ccf10bd746aaca2bc2918463dc76def4f6cb16ab788c5584bbc40d99d2d7bb6a78e6a7d35dfc6154864aa4194326eccbf0227c5d824b71e36e9f90fdc2d4b17e52541b4eec194e65d40d767e1b983b711cec9d17bdd93',
                  'coin_solutions': [{'coin': {'amount': 1750000000000,
                                               'parent_coin_info': '0xe0238891f563c0b04190f98aa3ca462304e9f1066d4be01c417d07a7994e8197',
                                               'puzzle_hash': '0x38737d10729bb92f459a2000545eb849d1694ae83e357e801f5cfbed6fd24a90'},
                                      'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b08138d9333b98960600df8faf6120bc56fdd85799c907732a18f85dfdf706f2a805afbc1d46756a9b3b926a814a6efa15ff018080',
                                      'solution': '0xff80ffff01ffff33ffa0c50cd93bf87bc50604a8c6ba4ffc7c74f8ad123e8ae92d2f928417d769c2b17cff8602bbcff318b180ffff33ffa04e5c713d2dc9daad94af550aeb6cd56c471d62f05801ee5f719f76a1a86441a2ff85699694b3f880ffff33ffa0537de8b8a1a78e1512862c800db1ad367a1a63f2f991946174222a2a6ddd76c0ff84009bb27580ffff33ffa00c9e8b32539ec4559c81dd272a4a29f608cd96641a4acc0f7dd9debecd2b4905ff850826299e0080ffff33ffa041533475e97f5a526cf85185226b008fb73fe8e4e005302f9ab6c317eef22ab5ff85015af49ae280ffff3cffa059f2e6f75b3debcee364d0ec952b7254a562c9921c38cd4406d570d32a7bcb418080ff8080'},
                                     {'coin': {'amount': 1750000000000,
                                               'parent_coin_info': '0xf30448c44f979fbb5659288b7bb7ae04f7778e924be9efa063b38ff497594879',
                                               'puzzle_hash': '0x38737d10729bb92f459a2000545eb849d1694ae83e357e801f5cfbed6fd24a90'},
                                      'puzzle_reveal': '0xff02ffff01ff02ffff01ff02ffff03ff0bffff01ff02ffff03ffff09ff05ffff1dff0bffff1effff0bff0bffff02ff06ffff04ff02ffff04ff17ff8080808080808080ffff01ff02ff17ff2f80ffff01ff088080ff0180ffff01ff04ffff04ff04ffff04ff05ffff04ffff02ff06ffff04ff02ffff04ff17ff80808080ff80808080ffff02ff17ff2f808080ff0180ffff04ffff01ff32ff02ffff03ffff07ff0580ffff01ff0bffff0102ffff02ff06ffff04ff02ffff04ff09ff80808080ffff02ff06ffff04ff02ffff04ff0dff8080808080ffff01ff0bffff0101ff058080ff0180ff018080ffff04ffff01b08138d9333b98960600df8faf6120bc56fdd85799c907732a18f85dfdf706f2a805afbc1d46756a9b3b926a814a6efa15ff018080',
                                      'solution': '0xff80ffff01ffff3dffa069ece43c9c7f4f9c97a3cc5674b2d1fd5eaf51b2cafff0dd5084e2bc2def9bd28080ff8080'}]},
 'to_puzzle_hash': '0x0c9e8b32539ec4559c81dd272a4a29f608cd96641a4acc0f7dd9debecd2b4905',
 'trade_id': None,
 'type': 1,
 'wallet_id': 1}
INFO:root:Total amount claimed: 3.5
INFO:root:Pool coin amount (includes blockchain fee) 0.035
INFO:root:Total amount to distribute: 3.465
INFO:root:Paying out 1102 mojo / point
INFO:root:Will make payments: [{'puzzle_hash': <bytes32: 0c9e8b32539ec4559c81dd272a4a29f608cd96641a4acc0f7dd9debecd2b4905>, 'amount': 35000000000}, {'puzzle_hash': <bytes32: 537de8b8a1a78e1512862c800db1ad367a1a63f2f991946174222a2a6ddd76c0>, 'amount': 2436522}, {'puzzle_hash': <bytes32: 4e5c713d2dc9daad94af550aeb6cd56c471d62f05801ee5f719f76a1a86441a2>, 'amount': 351939914828}, {'puzzle_hash': <bytes32: c50cd93bf87bc50604a8c6ba4ffc7c74f8ad123e8ae92d2f928417d769c2b17c>, 'amount': 3110093326398}]
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Not confirmed. In mempool? True
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Not confirmed. In mempool? True
WARNING:root:Pending payments (1), waiting
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Not confirmed. In mempool? True
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: -1
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 0
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 2
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 2
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 2
WARNING:root:Pending payments (1), waiting
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 2
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 2
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 2
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 3
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 3
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 3
WARNING:root:Pending payments (1), waiting
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 4
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 4
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 4
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 4
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 4
WARNING:root:Pending payments (1), waiting
INFO:root:Waiting for transaction to obtain 6 confirmations
INFO:root:Confirmations: 7
INFO:root:Farmer 8e86495a1a2b33f1875d554dc59960f5f71cd537f1f00530e35d2b69ae0039588593c0cc677b651f484d752f0fb5e109 updated points to: 958094142
INFO:root:Successfully confirmed payments [{'puzzle_hash': <bytes32: 0c9e8b32539ec4559c81dd272a4a29f608cd96641a4acc0f7dd9debecd2b4905>, 'amount': 35000000000}, {'puzzle_hash': <bytes32: c50cd93bf87bc50604a8c6ba4ffc7c74f8ad123e8ae92d2f928417d769c2b17c>, 'amount': 3005670955185}, {'puzzle_hash': <bytes32: 4e5c713d2dc9daad94af550aeb6cd56c471d62f05801ee5f719f76a1a86441a2>, 'amount': 453497893880}, {'puzzle_hash': <bytes32: 537de8b8a1a78e1512862c800db1ad367a1a63f2f991946174222a2a6ddd76c0>, 'amount': 10203765}]
INFO:root:Submitting a payment: [{'puzzle_hash': <bytes32: 0c9e8b32539ec4559c81dd272a4a29f608cd96641a4acc0f7dd9debecd2b4905>, 'amount': 35000000000}, {'puzzle_hash': <bytes32: 537de8b8a1a78e1512862c800db1ad367a1a63f2f991946174222a2a6ddd76c0>, 'amount': 2436522}, {'puzzle_hash': <bytes32: 4e5c713d2dc9daad94af550aeb6cd56c471d62f05801ee5f719f76a1a86441a2>, 'amount': 351939914828}, {'puzzle_hash': <bytes32: c50cd93bf87bc50604a8c6ba4ffc7c74f8ad123e8ae92d2f928417d769c2b17c>, 'amount': 3110093326398}]
ERROR:root:Error making payment: {'error': "Can't select amount higher than our spendable balance.  Amount: 3497035677748, spendable:  682189676671", 'success': False}
INFO:root:Submitting a payment: [{'puzzle_hash': <bytes32: 0c9e8b32539ec4559c81dd272a4a29f608cd96641a4acc0f7dd9debecd2b4905>, 'amount': 35000000000}, {'puzzle_hash': <bytes32: 537de8b8a1a78e1512862c800db1ad367a1a63f2f991946174222a2a6ddd76c0>, 'amount': 2436522}, {'puzzle_hash': <bytes32: 4e5c713d2dc9daad94af550aeb6cd56c471d62f05801ee5f719f76a1a86441a2>, 'amount': 351939914828}, {'puzzle_hash': <bytes32: c50cd93bf87bc50604a8c6ba4ffc7c74f8ad123e8ae92d2f928417d769c2b17c>, 'amount': 3110093326398}]
ERROR:root:Error making payment: {'error': "Can't select amount higher than our spendable balance.  Amount: 3497035677748, spendable:  682189676671", 'success': False}

opened by tmoore22 7

It's to easy to cheat as a pool admin...

https://chiaforum.com/t/suspicious-pools-what-is-happening/10830/69

I had to close this issue too, due to personal harassement for it and identity usurpation. I have a familly to protect.

opened by Tocard 6
pool: Fix subtract the points from each farmer

I am not sure if my understanding is correct, but I think the operation of subtracting each farmer’s points should be put until the transaction is completed. otherwise, if the program exits unexpectedly, the subtraction of each farmer’s score may be successful, but the transaction fails. If the program is restarted, all farmers’ points are already 0.

opened by jianghushinian 6

[Error] Request Entity Too Large

I got an error below in testnet, 1.2.3.

ERROR:root:Unexpected error in collect_pool_rewards_loop: 413, message='Request Entity Too Large', url=URL('https://localhost:8555/push_tx') Traceback (most recent call last):
  File "/home/chia/testnet/pool-reference/pool/pool.py", line 332, in collect_pool_rewards_loop
    push_tx_response: Dict = await self.node_rpc_client.push_tx(spend_bundle)
  File "/home/chia/testnet/pool-reference/venv/lib/python3.8/site-packages/chia/rpc/full_node_rpc_client.py", line 162, in push_tx
    return await self.fetch("push_tx", {"spend_bundle": spend_bundle.to_json_dict()})
  File "/home/chia/testnet/pool-reference/venv/lib/python3.8/site-packages/chia/rpc/rpc_client.py", line 42, in fetch
    response.raise_for_status()
  File "/home/chia/testnet/pool-reference/venv/lib/python3.8/site-packages/aiohttp/client_reqrep.py", line 1000, in raise_for_status
    raise ClientResponseError(
aiohttp.client_exceptions.ClientResponseError: 413, message='Request Entity Too Large', url=URL('https://localhost:8555/push_tx')

I think this is because my pool server has offline long time for about 4 days.

Does the HTTP server need to fix this problem? I think it is related to the upload size.

bug

opened by nicezic 11

subtract the points from each farmer

I think the operation of subtracting each farmer’s points should be put until the transaction is completed. otherwise, if the program exits unexpectedly, the subtraction of each farmer’s score may be successful, but the transaction fails. If the program is restarted, all farmers’ points are already 0.
enhancement

opened by jianghushinian 0
Can't find the difference between the plot files belonging to different singleton for same users, when I run the command 'chia plots check'

Can't find the difference between the plot files belonging to different singleton for the same user, when I run the command 'chia plots check',there is no parameter to distinguish which files belong to which singleton，so how to use commands to distinguish files belonging to different users,will this feature be added later in the 'chia-blockchain' project?
enhancement

opened by daxionga 2
[BUG] Pool can run out of available balance because of low pool fee

Having the pool fee hardcoded presents an issue where if lots of miners are participating the pool can run out of funds.

If the total transaction fees + miner rewards > block reward (this would be extreme and probably a flood case) or total transaction fees > pool fee.

Instead the fee should be a multi part calculation.

The pool takes a flat fee (or percentage of reward) and then the total cost for transaction fees is calculated by the number of transactions required, then the remaining balance is what is divided up into the transaction amounts. Well or something along those lines anyway...
enhancement

opened by ByronAP 4