For regular groups, we require that the owner adds/removes the admins, so group membership is adequately checked. However for null-owned groups this check is skipped. So we need an additional condition to prevent non-group members from issuing a transaction for approval by the group admins.
* The dev group (ID 1) is owned by the null account with public key 11111111111111111111111111111111
* To regain access to otherwise blocked owner-based rules, it has different validation logic
* which applies to groups with this same null owner.
*
* The main difference is that approval is required for certain transaction types relating to
* null-owned groups. This allows existing admins to approve updates to the group (using group's
* approval threshold) instead of these actions being performed by the owner.
*
* Since these apply to all null-owned groups, this allows anyone to update their group to
* the null owner if they want to take advantage of this decentralized approval system.
*
* Currently, the affected transaction types are:
* - AddGroupAdminTransaction
* - RemoveGroupAdminTransaction
*
* This same approach could ultimately be applied to other group transactions too.
Using the feature trigger timestamp here should be much less error prone than a whole new block message version. Once mempow has been live for at least 24 hours, the feature trigger can be removed and the code cleaned up, as all online accounts signatures will use the new format from that time onwards (legacy signatures are trimmed after 24 hours).
Due to the large amount of data, it can take some time for the request to be processed and data to be transferred. It may make more sense to load the initial state from the standard API, and just use the websockets for updates.
This should fix 500 error which could prevent forced refund attempts for LTC and other chains. It wouldn't have affected any normal trade-bot refund functionality.
This allows for different share bin distribution starting at an undecided future block height. This height will correspond with the QORA reduction. New values decided in recent community vote.
This allows the QORA share percentage to be modified at different heights, based on community votes. Added unit test to simulate a reduction.
# Conflicts:
# src/test/java/org/qortal/test/minting/RewardTests.java
This rewrite may have been causing problems with connections in the network, due to peers being forgotten too easily. Reverting for now to see if it solves the problem.
This reverts commit d81071f254.
# Conflicts:
# src/main/java/org/qortal/network/Network.java
If this proves to not have any significant bad effects on re-orgs, we could consider setting these even higher or even disabling the auto disconnect by default.
