Proofgold 0.2.1(rc3)

by BlakeKeiller, Monday, December 07, 2020, 15:10 (293 days ago)

Here is a new release candidate for 0.2.1:

This should be the final version unless a serious problem is found. I expect to release the "official" version of 0.2.1 this week after completing some final tests.

A number of improvements were suggested by some third parties. I don't know if I have permission to give them credit, so I'll wait to see if they want to take credit.

There are many changes and I'll briefly list the main ones and then describe them in more detail in replies below.

1. The new reward bounty fund activated by the hard fork will be via a smart contract with a veto clause.

2. The client is being rebranded as "Proofgold Core" opening the possibility of having other clients by distinguishing between the network with the client software.

3. There are new configuration parameters affecting how much memory is used.

4. There are new commands for automatically swapping proofgold bars with litecoin.

Reward Bounties via Smart Contract with Veto Clause

by BlakeKeiller, Monday, December 07, 2020, 15:15 (293 days ago) @ BlakeKeiller

The hard fork at Block 5000 (estimated to happen near Christmas) will stop creating 25 bar bounties at random propositions. There was a discussion period in October, but no clear agreement on what to replace it with. In the end I decided to spend 10000 blocks (about a year) with the new 25 bars intended to be bounties at each block to be controlled by an address for which I have the private key. I would decide what (meaningful) propositions to place the bounties on, hopefully with input from others in the community.

There has been some resistance to this option because it obviously places too much power in my hands. An option suggested and implemented since the last release candidate is to send the new 25 bars to a smart contract with a veto clause. After a staker creates a new block, the staker will have 48 blocks to "veto" allowing me to collect the 25 bars for the reward bounty fund. If someone vetos, they should send 25 bars to a proposition of their choice. After 48 blocks, I can collect the 25 bars for the reward bounty fund and use it to place bounties on propositions of my choice.

There are ways this could go wrong.

It is easy to create a theorem that can only be proven by a specific person. For example, the theorem could say "there exists an x such that sha256(x) = y." Only someone who knows x can prove the theorem. Creating a bounty at a proposition like this is a roundabout way of sending the funds to yourself while technically complying with the obligation to create a bounty.

I cannot define what a "meaningful proposition" is, but propositions like existence of preimages of hashes do not qualify as "meaningful".

If stakers (including me) were to start placing bounties on "meaningless propositions" (or gaming the system in some other unforeseen way), this should be clear by auditing the proofs published into the blockchain. I know I won't (purposefully) create bounties on meaningless propositions, but I will make it a point to explain and make public what propositions I am putting bounties on so that it is clear to others who want to audit what is happening. Likewise, if someone vetos the bounty fund and places bounties on propositions, they should post to the forum explaining what the propositions are. (It is possible to post to the forum from the software anonymously.)

In case someone wants to veto and place a bounty on a proposition they don't need to explain or justify, they can take the propositions from Mizar's MML and HOL4 proposed by Brown here:

Small files with the names of the problems and the correspond Proofgold address are here:

As long as users choose to put bounties on one of these addresses (assuming the proposition has not yet been proven) there is no need to justify choosing the address for the bounty.

To be concrete there is a new command vetobountyfund that can be simply used like this:

vetobountyfund <blockid> <address>

The easiest way to use it is to choose an address from the files linked above. The command should take care of placing a bounty of 25 bars (minus transaction fees) at the address.

Of course, a simpler possibility is that stakers simply veto to collect the 25 bars and not place a bounty at all. If this starts happening with a small staker, we can quickly modify the code to start orphaning all blocks created by that staker. If it starts happening with a large staker, then we will have to have a serious discussion about the future of the network.

Rebranding Client as Proofgold Core

by BlakeKeiller, Monday, December 07, 2020, 15:17 (293 days ago) @ BlakeKeiller

It seems like there might end up being a separate code base for another version of the client. In particular this repo was pointed out to me:

To avoid confusion, I've started releasing the client as "Proofgold Core". As long as other clients have a similar "brand" name in addition to a version number, there should not be any confusion.

It's dangerous to have separate clients for a cryptocurrency network because if they don't completely agree on the consensus rules, there can be a fork into two chains. But this really isn't something I can control and I definitely welcome the idea of other people working on the code base.

Proofgold Core is purposefully not being developed on github since github does not support anonymous developers. I purposefully included a messaging system in Proofgold Core so that anonymous developers (and users) would have a way to contribute, and it's important to me to support this option for anonymous developers.

I think the only realistic way to have the best of both worlds is to make it clear they are two different clients (Proofgold Core vs. a client developed by identified people on github) for the same network.

Rebranding Client as Proofgold Core

New Configuration Parameters

by BlakeKeiller, Monday, December 07, 2020, 15:19 (293 days ago) @ BlakeKeiller

There are three new configuration parameters. Some of these can be set depending on the amount of RAM your node has and make it run faster if you have enough RAM.

Two parameters affect garbage collection:

gc_space_overhead (default 80) and gc_stack_limit (default 104876)

With, say, 4GB of RAM it is probably safe to set gc_space_overhead to a higher number like 160 (or maybe higher). With a lot of RAM you might try a value like 1000. Of course, if your memory is limited, you can also set it lower than 80.

One parameter affects the caches for the database:

db_max_in_cache (default 100000)

It does not seem like setting this to a high number like 100000 needs too much RAM, but if it eventually does start needing too much RAM, the parameter can be lowered. It can also be set even higher, of course.

Atomic Swaps with Litecoin (Faucet and Initial Market)

by BlakeKeiller, Monday, December 07, 2020, 15:30 (293 days ago) @ BlakeKeiller

There are new commands allowing nodes to coordinate atomic swaps exchanging Proofgold bars for litecoins at specified price. Proofgold generally has the disclaimer of "use at your own risk", but this should be emphasized with this new feature. Under normal operation of the network, there should not be a risk of losing funds, but I cannot guarantee normal operation of the network. If your node dies for 48 blocks (about two days), funds can be lost. And, of course, if there are bugs in the code, funds could be lost in other unforeseen ways.

Due to the experimental nature, I would recommend that people only use this (for now) with relatively low values. To be specific, I will not use this with values over 1 litecoin or 1000 bars, and recommend others have these limits (or stricter).

Atomic swaps should help newcomers obtain a relatively small amount of Proofgold bars for experimentation. Atomic swaps can also be the seed for an initial market.

By default client nodes will not engage in swapping (or notice that others are swapping). To enable swapping, put


in proofgold.conf or start proofgold with the -swapping command line option.

The proofgold.conf also needs to have at least one bech32 litecoin address marked as a trade address, like this:


The trade addresses should be different from other ltcaddress addresses in the proofgold.conf file. (Those others are used to create burn transactions for staking).

Here are the most important new commands for atomic swaps and how to use them.

Suppose Alice has 0.0015 litecoin (LTC) and wishes to buy 100 bars (PFG) at a price of 0.000015 LTC:PFG (about 1 eurocent per PFG bar at current prices). She can use the createswapbuyoffer command like this:

createswapbuyoffer <address> 0.000015 100 0.0015

The address should be one Alice has in her wallet. The command newaddress can give her a new address if she needs one.

When Alice does this, assuming an ltctradeaddress has enough litecoins, a litecoin transaction will be sent to herself. The first output of the transaction is an OP_RETURN giving the relevant buy offer information. The second output is the 0.0015 litecoins to be spent for the bars. (An optional third output will be change.)

This buy offer will be visible to all other nodes with swapping enabled. All current buy offers can be listed with the "buyoffers" command.

Alice can cancel the buy offer by spending the first txout of the litecoin transaction back to herself. The command "cancelswapbuyoffers <ltctxid>" can do this for her.

Buy offers like the one above are public. Sell offers are private and are only known to the local node.

If Bob is willing to sell between 100 and 300 Proofgold at a price of at least 0.00001 LTC:PFG, he can issue the following command:

createswapselloffer 0.00001 100 300

If Alice and Bob have both done this, then Bob's node will recognize that there is a match. Without going into full technicalities (explanation available upon request), Bob's node will create an unsigned litecoin transaction that could send Alice's 0.0015 ltc to his address. He then creates a smart contract that will allow Alice to spend from the contract if the unsigned litecoin transaction is signed, published and has 3 confirmations. Bob can spend from the smart contract after 48 blocks (two days) in case Alice does not accept the match offer. Bob's node then sends 100 bars to the smart contract with a Proofgold transaction of a special form. When Alice sees this Proofgold transaction (and it has 3 confirmations), her node can sign the litecoin transaction and publish it. After it has 3 confirmations, Alice can spend the 100 bars at the smart contract to an address she controls. She must do this before the smart contract is 48 blocks old, or Bob can retake the bars.

Assuming Alice;s node accepts the match offer, signs and publishes the litecoin tx and then collects from the smart contract, she will have 100 PFG bars (minus transaction fees, so really ~99.999) and Bob will have 0.0015 litecoins (minus transaction fees, so really ~0.00149).

On average a successful exchange like this should take 3 to 4 hours after there is a match.

Bob can cancel all his current sell offers with the command "cancelswapselloffers." Bob can see his current (local) sell offers with the command "selloffers".

In case an atomic swap does not seem to have worked, check the debug.log file (in .proofgold) for information about what may have gone wrong.

Again, this feature is "USE AT YOUR OWN RISK" and I highly suggest not placing buy or sell offers of high value.

Atomic Swaps with Litecoin (Faucet and Initial Market)

by BlakeKeiller, Monday, December 07, 2020, 15:30 (293 days ago) @ BlakeKeiller

After 0.2.1 is officially released, I plan to keep at least one sell offer active at a time, initially for 10-100 PFG bars at a price of 0.00015 (about 10 eurocents). The intention is for this to act as a simple faucet with the (0.0015-0.015) mainly as spam control. If I see trades happening near 0.00015, I'll increase this "ceiling" price for the "faucet". I will also check for buy offers with a lower price and decide at the time whether to meet the offer.

RSS Feed of thread
powered by my little forum