I feel out of the loop on "the plan", but for now I am just trying to pay my expenses so I am focusing on working hard through my other freelance clients. I cannot put much time on building the protocol unless I am getting paid a reasonable amount (at least 500 USD a month). I don't think there is a huge rush to change the protocol now, but a design of an innovative marking/repuation protocol needs to move forward in order to remain competitive. Also, distractions, like how to reward miners to make the price go higher need to be toned down.

It's good to work with other projects, but we have to make sure it will really be something that users will value, and not just a way to get more funding.

The only feature that I really care about is Segregated Witness because most Lightning Network software relies on it (though it is not strictly necessary for Lightning). The faster syncing and possible DoS/security fixes would be important too. Luckily the current vulnerability being patched for Bitcoin Core 0.14-0.16 (which allows for inflation) does not affect us.

By the way I did a quick audit of the code starting at Mark Pfennig (Nathan Rixham)'s initial "global rename" commit and indeed it seems to be an exact copy of Bitcoin Core v0.9.2.1, other than renaming "Bitcoin" to "Bitmark". I also looked at his other commits before and didn't find anything dishonest. Thus, I am very convinced now that the code is honest and secure (up to the security of Bitcoin Core v0.9.2.1). Yes Nathan ran away with people's money (from what I heard), but he didn't (from my audits) code anything dishonest into the protocol. It is unlikely he would put something malicious into the git commits since anyone can view them publicly, but of course it is worth checking it some more.

By the way, I already applied to list BTM on Bisq (decentralized exchange). It may take a few weeks for it to get into the next release. But weird that Polo is dropping BTM, I guess the fork caused too much disruption. I'd like to see if those 2.5 million coins actually move.

Also I think cryptopia, trade-by-trade, and others are trading it. I need to setup an account on trade-by-trade to see how it works.

Actually it is not fully my idea. I implemented something similar when being hired to work on an altcoin. I didn't think much of it at the time, but now realize it can help to make mining more competitive. But it is not a silver bullet and I am still pondering whether it will make much of a difference. I think it will help, but I want to see people really demanding this before I work on a pull request for Bitcoin.

That plot is from a blog of a Bitcoin Cash (BCH) supporter. He talks about various sophisticated statistical concepts, without showing the math, and even uses "miners will blacklist the IP address of selfish miners" as an argument. I wouldn't assign much credibility to that analysis, though it has some amount of truth, it is not a full, unbiased analysis of the situation. Even if his model is correct, selfish mining isn't the only attack I'm concerned about, as I have mentioned in previous posts of this thread.

If an algo can already be "attacked" by merge miners, then those merge miners can become native miners and attack it also. So it is better to change the algo completely if you really want a different way of mining it. But changing algos needs to be done properly, not just with a centralized group of developers handpicking new algos whenever they want. Anyway there is already a good amount of native mining going on for about half the algos. Argon2 is only merge mineable with Unitus which is a tiny coin, equihash still no merge mining happening with Zcash because it requires more understanding of the code. Only sha and scrypt are really dominated by other chains. Monero we don't have to follow, we can leave it as it is and follow them later on. So I don't know what you're complaining about, there is already a good mix of native and merge mining, and nothing needs fixing, except for the overflow bug which should be done soon. I already told you what I agree with / don't agree with, and I only want to work on something that supports my vision, I have no interest in working on sloppy code just for the purpose of pumping the price.

If you follow the discussion since July, you will see that I was ready to work on a Marking protocol months ago, and one that I think has the potential to bring a lot of user demand. But dbkeys (and some others) wanted to fork, and I strongly opposed it. For now, the fork is not happening, but there is still some things stirring, and if people really want to change the mining system, then at least with my automated system it will happen fairly, with less politics, and no messy patchwork of forks that make the coin look like a joke.

If we can't even agree on such basic things, then who knows how messy it will be now to create the "marking protocol".

As for Monero merge mining, I don't care so much, it can be delayed without much problems.

For the time for peak hashrate calculation (1 year) I think it is good because it is the time needed for a full rotation of the Earth about the Sun. Yes maybe in the Northern hemisphere, summers in June-August may make mining more costly, but we should encourage decentralization, thus that should be offset by mining in the Southern hemisphere. As for EMP/UFO/asteroid attacks, we have no obligation to protect from them in the protocol, but of course we should adapt to changing conditions. If all continents except Australia get attacked by "aliens" then you are left with a centralized group of miners in Australia, and if the peak hashrate requirement dissipates quickly, they will have no incentive to help the other parts of the world to rebuild and make mining competitive again. They will probably attack the other parts of the world (take out the competition). I don't know why I am still responding to these obvious/troll questions.

What I can work on is to develop an automated system for changing algos. I think we should keep 8 algos, and just change 1 at time in an automated way using a rigorous voting process and deterministically compiled binaries for the algo specification. In order to replace a new algo, we should have 75% vote from all 3 parties: users, investors, and miners. We look back at the last 5000 blocks (1 week), and this is in line with Bitcoin which uses 1000 blocks for fork activation and 10 minute block time. The blocks/transactions used for voting will include the hash of a deterministically compiled binary that specifies the algorithm, so that it is absolutely clear what is being voted on. Also, the weight to assign to the algo should be included (set some limits on this). The source code should be distributed in a way that anyone can exactly reproduce the binary (that's what I mean by deterministic). Miners/validators don't have to work with the same binary, but should be able to prove it's the same algorithm by comparing their source code with the source code that we distribute for producing the deterministic binary.

Once a new algo is activated, the block reward should be equal to the average of the block rewards of the other algos for maybe 5000 blocks, to prevent abuse by people creating new algos just to have easy mining.

If all 3 parties agree to replacing an algo with some new algo that no other chain mines (thus is basically native), then it can happen. It would look bad on Bitmark in my view if this became abused, but at least it is done within a fair system, and the algos can improve in the future. We already have a lot of native mining going on and actually I would propose to replace Cryptonight with the new cryptonight that monero will use in October. That would give us a lot more honest hashing power in my view.

Basically, with mining you want to maximize honest hashing power. A miner is providing honest hashing power if he doesn't attack (double spend, censor transactions...). The expected value of the honest hashing power is h*P, where h is the hashrate and P is the probability that a miner is honest. For native mining, it is not hard to imagine P being greater on average, though h is very small and there can be quick burst attacks where dishonest miners suddenly flood in, so variance is high on honest hashpower and expected value is low when you are a small coin. That's why I think merge mining is safer, so if you're going to propose a replacement algorithm, you should have a justification for why it will increase the honest hashing power.

Another thing I would support is reducing the max block size to 200 kB to prevent spam, allow a fee market to develop, and ensure good decentralization. Bitcoin uses 1 MB per 10 min, so for 2 min, 200 kB makes sense, and Segwit can be added if needed. This would also be useful if we have a user voting system, as currently fee requirements are minimal, so it is cheap for people to create many transactions that support their vote.

Maybe you can fool others with this but making some algos native only would obviously benefit those who want to mine and gather Bitmarks easily without much competition, and in the same time reduce supply on exchanges. And then "conveniently" the lookback period is less to give these native miners more rewards. Maybe people don't realize this but blockchains are very unintuitive. There are no real world analogies to blockchains. Details matter. One small detail is the difference between a serious cryptocurrency and a joke. So it's your choice...

In general any change should show support from all 3 parties who have an interest in Bitmark: users, investors, and miners. Users can show support by voting when they make transactions (weighted by fees). Investors can show support by voting with stake (weighted by amount owned). Miners can show support by voting with hashpower. In the end users decide, since investors will follow users, and miners will then follow them since they want the highest market value of the coin they mine. But there should be a guideline written in the wiki that all 3 parties should agree with a strong supermajority (95%) in order to make a change to the protocol. If there is a division, then better just fork into 2 coins.

I already learned not to trust dbkeys, so I will try my best to get an exchange to support my "uncorrupted" vision. Like that if I do a bunch of work on Bitmark, at least there is a chance it can continue being used. But I also need support from people who support my vision.

By the way, I already have a 0.9.7.3 (with technical fixes) released on the bitmark-protocol repository: https://github.com/bitmark-protocol/bitmark/releases/tag/v0.9.7.3
It requires 950 out of the last 1000 blocks to signal it in order to activate. I even have a 0.9.7.4, with stricter block reward requirements, so people can signal for that too.

I don't know what your plan is @dbkeys but I don't support any sneaky moves. 9 th algo I don't see a point, it would just overcomplicate things, and any new algo changes I think should be done through proper miner (and perhaps user) voting systems to remove special interests biasing it. To increase the effect of CEM by more than 50% also looks sneaky, as does changing the time to look back for peak hashrate. Even if there is good reasons (I don't see them), doing them after the parameters are already set allows for special interest manipulation, and that's why I recommend user voting to sort things like this out. And reducing the total emission rate, of course I can't support even if you just make it affect some algos. I don't know if there's a point to try to compromise with me because I don't have any interest to work on something that is "hand-waved" and not following the highest standards.

@aliashraf
I think you are overcomplicating things. PoW is useful because it allows for trustless consensus. PoS needs some kind of "social network" to function, in order to know what the "real" chain is.

As for energy consumption, I don't see it as a problem. What I see as a problem is centralized energy consumption. Without large forces of centralization I don't think it would be possible to damage the environment in a significant way, and maybe even total (global) energy consumption would decrease. Also, merge mining would help to keep energy consumption for efficient, as you can mine multiple blockchains in the same time for the same energy cost.

As usual, incompetence walks hand-in-hand with scams. What serious developer would want to work on a scam? And no I'm not using some weird definition of scam. The fork pushed by dbkeys does 2 main things:

1) Transfers wealth from new investors to old investors (total wealth depends on demand)
2) Reduces security for users

and it is advertised as an "improvement"

If this isn't a scam then what is?

The dependence of emission rate on value of Bitmark relative to other chains was never part of the protocol, and it's basically a parametrized if statement:

If wealth of current investors is x, then take 1/x wealth from new investors.

And by current investors I mainly mean the early investors. People who just bought yesterday can still benefit from fair prices tomorrow. The earlier you bought, the more benefit you get from this fork. x would have to be big (market cap of Bitcoin) for 1/x to be negligible, so once (if) dbkeys with his 1 million coins is a billionaire, then the algorithm will allow for an almost fair emission rate (though you can't reverse what is essentially a premine caused by a past unfair rate). This is precisely a pyramid scheme, marketed as a decentralized cryptocurrency.

Obviously dbkeys told his friends to buy bitmarks right before the June fork, and when the price went down they got mad, so he wants to "regain their respect" (together with his own profit). So he thinks that by lying and stealing from other people he will regain the respect of his friends? Good luck with that.

Uncorrupted bitmarks reached $0.30 last week. I predicted $1 within a year from August 2018, so actually I think that can be reached must sooner. With uncorrupted bitmarks, the destination is moon. With scam bitmarks, the destination is dbkeys' pocket, and the amount is dependent on how many fools buy in.

I had some good discussions going on about selfish/colluding mining in the Development and Technical Discussion board (https://bitcointalk.org/index.php?topic=4998410.0). It is refreshing to talk to people who don't pretend to not understand what I'm saying. Though dbkeys / TeamBitmark did try to brigade it to push his agenda.

So if people want uncorrupted bitmarks, I can work on an exchange solution, but I need your support!

I want to amend some details in my proposal.

The reserved fees shouldn't be paid as transactions back to the users as that would waste too much space on the blockchain, and even if users aggregate all their fees into one address that changes once in a while, it would still waste space and be bad for privacy.

So I think each output in a transaction should be associated with a reserve fee (could be 0), and it would typically be the difference of f and f*h/p, where h and peak are the current and peak hashrates at the time of the transaction, and f is the full fee paid for the transaction divided by the number of outputs. This reserve fee can only be used when the next time the output is used as an input in a transaction (to preserve fungibility of coins), and it's value would fluctuate based on h/p (hashrate to peak hashrate ratio).

Think of it like this: When you send bitcoin to someone currently it is like sending someone a car without wheels. The car (the btc) needs wheels (fees) to get moved, so with this reserve fee associated with each UTXO you are giving the receiver a chance to send the btc with a fee that will fluctuate according to conditions. If hashrate rises, miners will chip away at the reserve fees created within the past 2016 blocks. At the time of spending the UTXO, whatever is left can be used for the mining fee. Yes in the end miners get all the transaction fees, but the ones they get at times of peak hashrate will be "unconditional" as they will not need a transaction associated with those, so they can fill their blocks with more transactions and take more fees. Also note that the "wheels" will be big for users during rough conditions (falling hashrate) and small during good conditions (rising hashrates).

Edit: I think better not to force the reserve fee to only work with the output it came with, because then people will select outputs based on fee preference, and that can be bad for liquidity or anonymity. Just leave the reserve fees as if they were independent UTXOs, except you can't spend from them; you have to use them as fees for transactions. This would increase the size of the UTXO database, but by a maximum factor of 2.

Currently, the most proof-of-work chain for Bitcoin is the one that most SHA256 work. If a hard fork is done that allows for continuation with some other algo, then the most proof-of-work chain would be defined differently. Maybe the definition would consider SHA256, but not exculsively. Even if the attacker gets more proof of work for SHA256, they would have a hard time getting more than Bitcoin for some other algo I assume. It depends on how it's done, so not sure, but either way it would be an ugly situation, and something we want to avoid.

Would be good to see how that pie chart changed before the rise and after (August 25 and August 27)


Merge mining is more useful for altcoins to prevent wild swings in hashrate and to increase the hashrate, which is necessary for security. Actually, it is the honest hashrate that you want to maximize. Honest meaning, a hashrate provided by miners that don't attack. The main attack to worry about is double spending, but also censorship of transactions is an attack a miner can carry out.
The expected value of the honest hashrate is
h * P, where h is the hashrate and P is the probability that any given miner is honest. For native mining (no merge mining), it would make sense that P is greater (the miner is more dependent exclusively on the coin), but if the coin has low value, h will be very small, so not worth it even if P is 1. Also the variance of h and P is probably larger with native mining. For Bitcoin h is large, so it doesn't matter so much if you do merge mining, and h * P may even be greater for native mining because of a larger P. But this can change, and anyway, merge miners still have some degree of loyalty to a coin they are merge mining together with another, and as long as Bitcoin has the dominant market value, the miner is still very dependent on it. The P can also depend on what kind of "rival" coins are out there, as rival miners would just want to damage coin in order to boost another coin.

Sidechains can help by providing other blockchains where miners get paid in Bitcoin, and I think better to not allow merge mining of sidechains simultaneously, only merge mine random other coins, but all Bitcoin sidechains should be independently mined (as well as their sub sidechains), so then you get a whole tree structure of side chains, and no miner can control all chains simultaneously, since they are not merge mineable. Sidechains still needs more work in zero knowledge proofs in order to be a trustless system. The best we can do now is lock coins in a multisig address when sending to a sidechain.

Multi-algo proof of work systems can also help to decentralize mining. If you let miners choose 1 of n algos for mining, then miners will likely want to specialize in one algo, instead of try to be a "jack of all trades", so it will be hard for one miner to attack all algos and thus the chain. Though one thing I like about SHA256 is that it is really simple, so someone can easily build an ASIC at home, or a small company can build it instead of rely on centralized manufacturers. So maybe multi algo with simple algos, not those complex algos designed to prevent ASIC mining, because for those it will be easier to be a "jack of all trades" mining everything with general purpose GPUs.

I think the 2 week block retarget with 4 times max increase/decrease is fine as it helps to prevent sybil attacks, but who knows, a more dynamic algorithm could work also.

As for my proposal to let users create "smart contracts" with miners dependent on hashrate, I think it would be easy to do because as with SegWit, there is an "anyone-can-spend" output that can be used to put extra fees that are dependent on hashrate conditions. The miner would have to add one anyone-can-spend output in his coinbase transaction that stores the reserves. There can be various contracts, but I think the standard contract should work like this: If hashrate keeps rising, then miners keep getting more rewards from those reserved fees, if hashrate drops, then the users who created those smart contracts would start getting their fees back.

The change would require new OP codes added the the script system that check for hashrate and peak hashrate. That wouldn't add much CPU time and we can add a limit of 4 years for the lookback period for the peak hashrate (anyway it would be cached in the blockindex / memory). The feature would be completely voluntary for both users and miners. I think with a chance of users getting some of their fees back, that would incentivize users to create such smart contracts with a larger fee than usual and miners would find them attractive since they can now can get more than usual amount of fees. The only issue is the UTXOs extra transactions needed (possibly increasing costs for users/miners). We want to make sure the UTXO database doesn't grow unnecessarily and any extra transactions don't waste block space. When miners get paid for the rising hashrate, they will need to make a transaction that spends some amount from each of the anyone-can-spend outputs that are still part of the reserve fees. Eventually, each of those outputs will get destroyed (multiple outputs converging to one), so I think a rising hashrate is good for destroying the extra UTXOs, and only 1 extra transaction is needed per block. The size of the transaction can be reduced by limiting the time window for such a smart contract to finish (would take a long time to dissolve the reserve if hashrate is only slightly increasing/decreasing). In the case of a falling hashrate, the anyone-can-spend outputs will split into many outputs (users getting their money back) for each block that is relevant, and that would require more block space than with miners getting paid, so maybe pay users only once the reserve is finished (i.e. contract is over), and make sure the time window for the contract is limited (like 2016 blocks for example). If the contract ends before the reserve is finished, the remaining reserve can be split evenly between miners and users, or some other specified rule.

The problem is

if

a) The attack is unsuccessful, the attacker loses a lot of resources

b) The attack is successful, the value of Bitcoin plummets (perhaps people switch to an altcoin or hard fork Bitcoin with a PoW change), and the attacker still loses a lot of resources.

It's more worth it for them to just mine honestly and get honest rewards, unless their only goal is to harm Bitcoin, in which case people will just switch to a more robust PoW system (like multi algo, merge mining), so don't see what they will gain.

@Heretic says:
I want to revist this scenario, assuming no merge mining. First, I think a price drop will be slightly offset by the lower rate of coins being mined. Also, confirmation times will get longer: Both the time to get a block will increase and the number of confirmations needed to have enough work done on the chain so that your transaction is considered safe. The fees would likely rise and this would increase rewards to miners, especially in a fee-market dominated future. It would be nice to write this up in terms of mathematical equations to see exactly what would happen.

Anyway, I am proposing just to modulate the fees (not the fixed subsidy). I think a good way would be to let users choose how their fees are used. If a user wants, they can say: "I am paying f h/p to the miner", where f is the nominal fee, h the hashrate of the past period (current hashrate), p the peak hashrate. So the miner who mines the block with that transaction will only get f h/p, and f-fh/p will be kept in reserve and can slowly be released to miners as the hashrate approaches the peak. For example, if once the current 144 block period is over, it is calculated that h2 > h, then h2/p-h/p will be released to miners who mine the blocks in the next period (perhaps spread evenly over that period). Like this each user can choose more precisely how they want their fees spent, and it makes sense that they would care about the security provided by blocks coming after the transaction they make, instead of just caring about the immediate block they get their transaction on.

Can this sort of thing be done easily with a soft fork or some kind of smart contract between users and miners? I don't know, I am thinking about it.

@Heretic says:
Also revisiting this...I think I should add another category of attacks that I am trying to prevent: subtle attacks that are profitable and don't significantly affect the price of Bitcoin. This could be block withholding attacks (mining pools wasting each other's resources), networking attacks (to mess with other miners' connectivity), physical attacks (like purposely selling defective hardware and for yourself mining with the good hardware). I think this is what Peter Todd was talking about in the Reddit post about "other subtle and more effective attacks", and he (and others) likely don't want to lay them all out to give attackers bad ideas. Even EMP attacks on general electric devices can be considered "subtle" as it can be done to look like just an attack on general devices, while really it is targetting an area dense with honest miners. The selfish mining attacks and collusion attacks (the other categories) can also be done quite profitably I think, but with Internet anonymity still immature, they are less practical (as Peter Todd also indicated). In general, the point of my proposal is to disincentivize miners from driving out the competition. With the same reward for a lower hashrate, it is profitable to drive out competiton (lower overall hashrate) as that gives a bigger share to the attacker, and the same reward. If someone knows other ways to achieve this goal, then please let me know. This is one simple way that I think would work.

I think phone is a hassle. You have to pull it out of the case, put the password, open the menu, go to the lightning app, scan some qr code, click pay... hopefully your battery is fine and you have signal. People already pay with cards these days. You can just give the cashier a card, they scan it, and it's done. You don't have to run a node at home if you don't want to, you can use a 3rd party service. It's not like full nodes are running on mobile phones anyway. I think all 3 methods should be supported and standardized at Point-of-Sale locations (phone, card, paper bills), and let people choose. The way I see it is Bitcoin: Be your own bank, Lightning: Be your own credit card company.

Like I said I open also to using a plastic (or other material) card that would work like a credit card with daily limits and approved merchants (identified with public keys). The paper bills would be a backup choice for untrusted merchants or when your phone battery dies, just a primitive way to pay without strings attached.