Mark Friedenbach

That's correct. There would be different sets of miners for the two algorithms. Pool services would run different pools for each. The length of the transition period and the allocation of subsidy between the old miners and the new miners is arbitrary in a sense. There's no technical reason for the choice, just soft factors like making sure that nobody is wronged by the transition and the community split as a result. A straightforward choice is to have a linear transition so that the subsidy given to sha256d miners is slowly stepped down and given to cuckoo cycle miners, over the course of

I would like to gather community opinion regarding a possible change to freicoin's mining algorithm. Right now we use the same proof of work algorithm as bitcoin, non-merged mined double-SHA256. I have for some time been an advocate of switching to a newer proof of work algorithm that has better protections against mining industry centralization, and which avoids price- and difficulty-based swings in hash rate between bitcoin and freicoin. However it has until now been thought that changing the proof of work for a chain is necessarily a hard-fork change, which I would be hesitant to suppo

You can specify other seeds with the '-s <seed>' command line option. We'll need to get a list of active seed servers together both as defaults for this tool and the official freicoind release.

Oops, I should have done a search first. I updated patches against sipa's bitcoin-seeder to work with the latest repo, and pushed those changes here: https://github.com/freicoin/bitcoin-seeder The commits are a little bit cleaner, perhaps.

Soft-fork activated on block 225687, no issues reported.

Given the recent rise in hash rate, the soft-fork seems very likely to activate today.

I don't know what's special about this block.. what is it failing on?

I've noticed from my logs that people have upgraded. I don't see any blocks being mined with the soft-fork version bit being set. If anyone is running their own mining that doesn't pass through the block template's version number (many don't), be sure to set the nVersion to 0x30000000 / 805306368. Or if it is version bits aware, that is the same as signaling bit #28.

Ah, I see, and I understand your point now. Alternatively though, since nearly every single release is going to be "vBitcoin.0-Freicoin" does it make sense to drop the ".0" except when it is used (nonzero)?

Well both are necessary--it's important to indicate whether it is the 1st, 2nd, 3rd, etc. released based off the specified bitcoin release. It is also important to indicate the sequential ordering of freicoin releases, which the old numbering scheme lacked. You can look to the last number, which will always be increasing, as the freicoin build number. Yes, these recent releases are very much a part of the effort to switch to newer bitcoin versions. The reason for these truncation soft-forks are to minimize the size of the freicoin patch against bitcoin and the required dependencies, in or

The version numbering scheme changes and I let that go unremarked; my apologies. We had a “v0.8.6-2” release (note the dash). This is a “-4” release. The dash number is / will be an always increasing freicoin build number, and the first three dotted version numbers are the bitcoin release it is based on. Under exceptional circumstances (like now) there will be multiple freicoin releases per bitcoin release. In these cases an additional dotted version number will be added.

Update: Release v0.8.6.2-5 has been posted to the freicoin website. This is a maintenance-only release that has no new features. Rather, it only takes the final step of stripping out the dependency on GNU MP and MPFR entirely, such that they are no longer needed even as build-time requirements. Notes for v0.8.6.1-4: There’s been a new release posted to the official freicoin website: v0.8.6.1-4. This release introduces the new integer-math-only demurrage calculation code as a soft-fork change to the consensus rules — the approximations in the integer math can make the result differ from th

Stellar would be an example of such a protocol. However see this paper from IBM's research division about the failings of such proposals: https://arxiv.org/abs/1707.01873

Arcurus, if you want to advance the idea of freirepublic / republicoin into production, I would suggest finding a way to fund research into self-organized byzantine fault tolerant consensus algorithms with rigorous formal proofs. This is the missing building block that would be required in order to have UASF-mandated use for subsidy towards specific causes in freicoin. To be clear, this is not me asking for money. I'm actually not a BFT researcher and am overworked as it is. Rather it is a necessary technology that must exist for this idea to be safely deployed, and something which (despi

> Is there still a need to have a refheight in the Freicoin transaction if so why? There's a couple of ways I can answer this question. First, there is always a need for refheight in Freicoin transactions just by definition: it would be a hard-forking consensus change to remove them. This is the technically correct answer but mention it only for completeness as I assume it's not what you meant. This doesn't affect the need for reference heights in any fundamental way. Reference heights address a problem that generally applies to demurrage in bitcoin-like block chains: the dem

A little bit of a technical update I want to share. As part of the refactoring and rebasing effort I've worked out a way to eliminate Freicoin's extra dependencies while at the same time achieving a 10x performance boost for the mathematical calculations we use these libraries for. I'm quite excited about this, although for reasons that might be obscure for those without a technical background. If you don't understand this post, that's okay. The TL;DR is that we can make Freicoin faster while further aligning the code base with bitcoin to minimize the maintenance burden. Freicoin uses the

Merry Christmas everyone! It's been a while since I posted here. My apologies. I've been quite busy getting a proposal for MAST implemented and reviewed, which is exciting in its own right [0,1]. I now have a bit more free time to devote to freicoin in the coming months. Back in September we agreed to wind down the foundation and to burn the left over funds after finishing the remaining charitable matches. I pulled out the donation matching code and started updating it to work with the current versions of its dependencies. However there was one snag that caught me by surprise: the sc

The last few posts got sidetracked onto a separate unresolved issue, but I think the core question of this thread is resolved: the delayed coin matching will be performed, completing our obligations for 1:1 donation matching, and then the remaining funds will be provably destroyed. The two blockers on this are updating the coin matching scripts, since code atrophy means they no longer run on recent versions of linux. The bigger problem is making sure that the funds being sent out are sent to wallets people still hold the keys to and haven't been compromised. I'll be reaching out to the contact

Bitcoin or Freicoin? Freicoin obviously doesn't have segwit until we complete rebasing and activation. Segwit is fairly well described in the bitcoin developer documentation on bitcoin.org, but probably the best thing to do is to switch over to an actively maintained bitcoin block explorer. I don't have a specific recommendation but I know here are several.

With a 1wp we cannot expect all coins to move to the new chain -- some wallets are lost for example, so when do you stop supporting old UTXOs? With a spinoff or hard fork it would be possible to inherit the old UTXO set, but at the cost of not being able to deprecate handling the old chain data structures. A sync from genesis requires understanding the old chain up to a certain height, then switching to code that handles the new chain. Alternatively you can dump the UTXO set and import it at the changeover height, but do you still handle old style transactions at that point? Do you flag day ex

Can you expand on that Jorge?

Thanks fedde, that's good to know! Certainly some review and testing of new releases would be helpful in allowing us to pipeline things.

I can't agree enough that we are currently limited by developer time. We need more developers. However I'm very cautious about the ICO craze. ICOs are securities offerings, and doing or promoting an unlicensed securities offering is a serious offense punished by massive fines, jail time, and a lifetime ban of working in the industry. People haven't been burned ... yet. But it's just a matter of time. It can be frustrating to watch developers with nearly zero experience raise huge sums of money for poorly defined projects, and even more frustrating to see the biggest offenders get a pass b

Hrm... I spent all morning dwelling on this and I think the situation might not be as hopeless as we (Jorge and I) thought before. I am on mobile and can't type a full description, but TL;DR mimblewimble demonstrates a mechanism for non interactively joining ballots together such that the resulting aggregate vote tally doesn't reveal the amounts of the individual vote. To limit loss of privacy if the federation is compromised or corrupt, you could do a coin join vote so that your individual holding is not revealed. I'm not sure how realistic that would be though.

Arcurus, all of the approaches I've seen described by you are either centralized, or vulnerable to attack if made anonymous and therefore trust/identity based. Please correct me if this is not the case. Republicoin was made nearly-decentralized by using proof of stake as a vote. 1 kria = 1 vote. However the problem is that the vote counting is done by miners in a chain, and while the miners can't create votes, they can censor them. So the miners really control the election by disenfranchising people they don't like. Not decentralized. There is a semi-trusted solution to this where a stron