Mark Friedenbach

Freicoin Developer
  • Content count

    47
  • Joined

  • Last visited

  • Days Won

    26

Mark Friedenbach last won the day on May 19

Mark Friedenbach had the most liked content!

1 Follower

About Mark Friedenbach

  • Rank
    Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

790 profile views
  1. Mark Friedenbach

    Changing the proof of work algorithm

    Sidechains and merge mining have their own intractable problems, and in particular they do not mix together very well (merge mining makes the sidechain problems worse, and vice versa). If freicoin were to be sidechain to another chain, it would have to either (1) be a separate proof of work, or (2) have all full nodes of both chains validate each other, an idea more commonly known as extension blocks. Setting freicoin up as a separately mined chain with a different proof of work (and therefore different hardware distribution) prepares for the first possibility while not excluding the second. But in reality I expect that freicoin will remain different from bitcoin and other coins, and not an active sidechain, except perhaps via strong federations or higher level protocols using cross-chain payment channels. There is at least one person I know who has made a recent ASIC purchase for freicoin mining, and I would hate to invalidate that investment. But the transition period also serves the purpose of having incentive for securing the sha256 portion of the network for some time to come, which helps protect other full nodes. In fact, current full nodes will be able to sync indefinitely into the future, even after the transition is complete, as the difficulty will have transitioned back down to diff-1, and all cuckoo cycle blocks will require a follow-up diff-1 sha256 block in order for the cuckoo cycle miners to actually collect their payment -- the trick which makes the soft-fork deployment possible.
  2. Mark Friedenbach

    Changing the proof of work algorithm

    Regarding ASIC reistance, it's a goal that in its strongest form is impossible. You cannot have an ASIC-reistant proof of work, and if someone is trying to tell you otherwise that's a good indicator you're dealing with a crank (or they're trying to sell you something). Anything you can do with a general application-agnostic circuit you can do more efficiently in a specialized circuit. This follows straight from information theory. HOWEVER, there is a weak form of ASIC-resistance which is interesting to note. With double-SHA256, GPUs are 100-1,000x more efficient than CPUs, FPGAs are 100-1,000x more efficient than GPUs, and ASICs are an additional 10-100x more efficient. Double-SHA256 ccould hardly be more ASCI-friendly. So the weak form of ASIC-resistance is an algorithm which, when implemented in specialized hardware, has the smallest possible advantage when when compared against consumer hardware like vector CPUs or GPUs. With Cuckoo Cycle, for example, the advantage gained by ASICs over GPUs is only an (estimated) 2-4x. Compare that with the more than thousand-fold improvement double-SHA256 sees. Why does this matter? Because in the event of an attack on the network, a disadvantage of 2-4x can be overcome by a wide decentralized base of users, perhaps motivated by investors favoring the decentralized chain over the centralized one (e.g. look to the price difference between BTC and BCH). The decentralized chain can withstand an attack by retreating to a popular base of GPU miners. With double-SHA256 however this isn't possible. If non-ASIC bitcoin users wanted to revolt against the ASIC industry, they would find that even if everyone mined they'd only get a block on their chain once a month or so. It would take the better part of a century to see the first hash rate reduction. Even with freicoin's faster difficulty adjustment it would still take years. That's not even close to being a realistic alternative, and therefore any resistance to centralization forces all the problems that come with hard forks. Weak ASIC resistance doesn't do anything to boost decentralization, in first order analysis. You'll still see creation of ASICs and their adoption within the mining industry. However it does enable fallback options whose very existance prevents the ills of centralization from happening. These are 2nd-order game theoretic effects. We've discussed both proof of stake and paxos consensus models before. The claims of these systems are analagous to perpetual motion machines. I really have no interest in going that direction, and would spilt ways with freicoin if that's what the community wants. > Why use a two way proof of work architecture? It's a necessary fact of being a soft-fork. The old clients need to see progress being made on double-SHA256 blocks. That's the only reason. > Isn't a double spend more easy in a two way proof of work architecture? No. > How can a simple difficulty algorithm look like? That's a bit isomorphic, but the difficulty algorithm would probably look a lot like the one in Freicoin today. The parameters could probably be better optimized, but ultimately the choice of a linear filter was correct is justified by its performance.
  3. Mark Friedenbach

    Changing the proof of work algorithm

    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 2-3 years.
  4. 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 support for a variety of reasons. But it turns out that's not the case! I recently invented a mechanism for phasing in a proof-of-work change as a soft-fork, with a transition between the two over months or more likely years that gives safety for the old clients during the transition, and is not too complex of a change either. So we now have the capability to change proof of work, to something slightly more ASIC resistant with better decentralization effects and less competition with bitcoin. Without getting lost in the weeds, I am specifically considering the Cuckoo Cycle proof of work, which you can read more about here: https://github.com/tromp/cuckoo Is this something the community could get behind? The parameters of the soft-fork transition would be set such that it would not invalidate any investment people have made into sha256d mining during the lifetime of the miners. I'm thinking 2-3 years for a full transition, during which time the reward does a linear transition from sha256d to cuckoo cycle. And it would probably take six months to implement anyway.
  5. Mark Friedenbach

    Working DNS Seeder

    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.
  6. Mark Friedenbach

    Working DNS Seeder

    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.
  7. Mark Friedenbach

    New release: v0.8.6.1-4 (soft-fork!)

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

    New release: v0.8.6.1-4 (soft-fork!)

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

    Bitcoin block 503460?

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

    New release: v0.8.6.1-4 (soft-fork!)

    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.
  11. Mark Friedenbach

    New release: v0.8.6.1-4 (soft-fork!)

    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)?
  12. Mark Friedenbach

    New release: v0.8.6.1-4 (soft-fork!)

    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 order to make it easier to rebase the code against more recent bitcoin versions. Since 0.8 the bitcoin source code has changed considerably between major releases making the rebasing otherwise a quite time consuming effort.
  13. Mark Friedenbach

    New release: v0.8.6.1-4 (soft-fork!)

    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.
  14. 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 the previous multi-precision floating point implementation by as much as 1 kria per input, although this error is biased in the direction that makes it soft-fork compatible with the old code. It does mean however that after activation any non-upgraded wallet code creating zero-fee transactions under the old rules is likely to create an invalid transaction. So upgrading (or paying fee) is mandatory! This new release includes activation logic to switch over to this new integer math code path in the consensus rules once there is supermajority support by the miners, OR at block height 229376, which is about 6 weeks away. Please be sure to upgrade by then! You can download official freicoin binaries and source code here: http://freico.in/download/
  15. Mark Friedenbach

    Draft - Freirepublic

    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