Mark Friedenbach

Well, 5 years later it's still not clear that a decentralized solution is even possible. And if it's not decentralized.. then what are we doing here? It'd be so much simpler to have a central ledger that manages demurrage in that case.

I will say that I am solely and exclusively interested in decentralized solutions only, in both the near and long term.

After the random value is released, I go back and make up a proposed block that's even closer. 

No solution, I'm afraid. Anyone can fork bitcoin, or freicoin, or any other crypto currency at any time and try to get people to use the new spinoff coin over the old one. This isn't the first time that it has happened to bitcoin either, just the first time that it had any significant (albeit minority) support from miners, users, developers, etc. There is not some crypto magic that would save us from this outcome -- I can think of generic approaches to replay prevention that would work no matter the underlying crypto system (e.g. XOR the signature with fixed data).

Difference of 2 satoshi/kria, actually. Lightning struck twice.

The wallet does not let you spend more than you have. This is not a bug or mistake. What happened was that about a year and a half ago we rolled out a soft-fork upgrade of the Freicoin network which changed the rules regarding how demurrage is calculated. Specifically it made it so that demurrage is truncated (rounded down) per-input instead of in aggregate over all transactions. Imagine a transaction that, after demurrage is calculated, results in 2 inputs that have 0.8 and 0.8 fractional kria each. Under the old rules these are represented as arbitrary-precision rational numbers that sum to 1.6 kria, which is then truncated to 1. Under the new rules, they are each truncated to zero before being summed as integers. 0 + 0 = 0.

While the old method was probably ideal in some mathematical sense, it required that every single piece of the freicoin code that worked with transaction values had to be modified to use arbitrary precision arithmetic. It was a huge drag on developer resources as patches many thousands of lines long had to be maintained and updated for each release. Indeed this minor technicality was one of the two main reasons we fell behind in maintaining the freicoin releases for each upstream bitcoin version (the other being lack of testing). The new method, on the other hand, confines the complex mathematics to a single 10-line function in a single file and only a few other points need to be updated to call that function. Much easier to maintain and well worth switching to.

However that does mean that if you create a zero-fee transaction using an old client (v0.8.3 or earlier), there is a small chance that you will trip this bug and claim one or two extra kria that you are not allowed under the new rules, thereby making your transaction invalid to any upgraded client. This was deemed to be an acceptably small risk for both theoretical and practical reasons. The theory is that it required paying zero fees, which is not the default even with nearly empty blocks, and even then had a low probability of happening. And pragmatically, we observed that in the 3 years or so that Freicoin had been in existence and in use, such a transaction had never, ever been made: the new-rules clients were able to successfully sync the whole chain without any exceptions being made. Finally, even if it did happen, that would not by itself lead to loss of funds -- the transaction would simply not confirm. Unconfirmed transactions is a fact of life in the greater bitcoin world and there are tools for dealing with them. Either make your wallet forget the transaction, upgrade, and sign again; or re-create it using the raw transaction API and manually adjust the amounts. Those are the two approaches I would take.

Mark. Murphy is a heartless bastard that enjoys picking on our friend Jert. Twice.

This transaction is invalid:

Quote

ERROR: CheckInputs() : 31c6b8767a7b1d7ab8ca6ef97d44749982324d8437cf15efd55e042bdc75afa4 value in < value out (3075.0305883 < 3075.03058831)

In plain English, this transaction spends more freicoins than are available to it after the inputs are reduced by demurrage.

It is possible to recover from this by creating a transaction using the most recent version of freicoind/Freicoin-Qt. In the worst case if the wallet software does not let you do this, as it is equivalent to double-spending, then export the private keys and import them into a new wallet and try from there.

I posted a little bit more about development roadmaps in the Future of Freicoin thread.

It's time to re-start this thread. As mentioned in another thread, I've been professionally busy non-stop for some months on a couple of different projects. That is currently slated to change with my new responsibilities including the maintenance of the Elements codebase, which includes most of the new features we would like to add to Freicoin. So there's a little bit of double-dipping there. Plus since I'll be traveling less and working normal hours I'll be able to spend 8-10 hours a week, evenings and weekends, working on the basic plan outlined at the top of this thread.

So let's revisit this thread. We did back-port some consensus bug fixes to the freicoin client and issued a new release of the 0.8 node software in 2015. Also included in that release was a soft-fork that changed the rules for demurrage calculation, in a way that will potentially make the client easier to maintain. We have not made good on our promise to update the client to newer versions of upstream Bitcoin Core, and that will be my first priority. The soft-fork change to demurrage calculations means that a little bit of up-front work is required to re-write those patches, but afterwards the total maintenance cost should be reduced.

The call for testers still stands. We need to develop some sort of test plan for new releases that gives us some assurance we aren't releasing bad code. Any help with this would be much appreciated.

Now looking at the specific features I suggested adding:

Quote

Lock-time improvements. Written by Peter Todd and yours truly, these are soft-fork enhancements which improve the utility of lock-time (allowing trustless micropayment channel setup, for example). These are soft-fork changes and ready to deploy today, although they are presently receiving review by the bitcoin community.

This is already in bitcoin, and will be in freicoin as soon as we upgrade the reference client to a more recent upstream version.

Quote

Segregated witness. Eliminates malleability concerns entirely, as well as yields significant performance enhancements to syncing the historical block chain. This is a hard-fork change, and currently undergoing minor improvements.

Likewise! Freicoin will get the same segwit that bitcoin is about to lock-in.

Quote

Confidential transactions. Allows selective disclosure of an output's value. Observers watching the chain have limited information about the values being transacted, thereby achieving an increased level of privacy. This is a hard-fork change, and currently undergoing major improvements.

Still want this for Freicoin, but:

Quote

Native assets. Also known as: freimarkets. Adds explicit asset coloring and corresponding accounting rules, and makes the transaction format more expressive so as to support pre-signed offers and other financial contracts necessary for a peer-to-peer exchange. Only the most basic version is implemented so far, and it is a hard-fork change.

In the time since I wrote this, Jorge and I along with our co-workers and a partner company implemented confidential assets, which is an extension of confidential transactions that blinds the asset being transacted as well as the amount. This was a significant amount of work, and basically occupied 12-14 months of my professional career, as well as that of my colleagues.

Part of why my enthusiasm for bringing CT to Freicoin waned after writing the above words is that as soon as Andrew Poelstra invented the necessary crypto component to make confidential assets work, it became clear that we would want to wait until this new CA was finished. Proper asset support has always been an essential part of my vision for Freicoin as it is necessary to construct other forms of decentralized money (e.g. classic ripple) as well as interesting smart contracts.

Confidential assets was released this year, and made more polished in the last few months in preparation for the BC2 conference, where the necessary features for distributed exchanges were also written. It's now in a state where we can talk about brining it into production on Freicoin.

Quote

A non-disclosed method for non-interactive CoinJoin. This is a hard-fork change, and presently still on the drawing board. More details to emerge as this is released as part of sidechain elements.

This was Mimblewimble!

No, I'm not secretly Voldemort, nor does Voldie work at my employer as far as I'm aware. However we were working on some similar ideas for non-interactive CoinJoin using confidential transactions and one-way aggregatable signatures. Voldemort independently invented the same tricks, and to his/her credit realized that it allowed A LOT more than just non-interactive CoinJoin.

It also turns out that it doesn't have to be a hard-fork change, other than the introduction of confidential transactions itself. Mimblewimble can be implemented on Elements Alpha without any changes. However it does need some work to reconcile with confidential assets, so some basic research here might be required. It is however high priority research at my employer and I am hopeful that we can see production-ready results on a relatively short timeframe.

The only other features not mentioned here are a bunch of little improvements to bitcoin script that makes writing smart contracts much easier or allows more powerful contracts. That might be a good topic for another post. Many of these are already implemented in the elements codebase, but just need some review and testing before production use.

Finally, a word needs to be said about merged mining. In fact this deserves its own post and I will make one in time, but the short TL;DR is that Jorge and I differ on our views about this. Given what we have seen happen in the Bitcoin space with respect to mining, ASICBOOST, and segregated witness, I no longer have faith that SHA256 mining can be used to secure a high-value network. And as bad as the situation is for bitcoin, it would likely be even worse for a merged mined coin, as in practice merge mining sees higher rates of centralization. I think there is a strong argument for switching to a new proof of work entirely, one which is not ASIC resistant (that's a unicorn that doesn't exist), but rather tries to minimize the performance gap between high-end general compute ad specialized hardware. Cuckoo Cycle is an example of one such PoW algorithm. In any case, I'll post my thoughts regarding this in another thread.

I hope others are as excited about bringing these new features to Freicoin as I am. I think the applications that can be built on top will do a lot to bring utility to freicoin as a medium of exchange for a generally useful block chain platform.

Skaro, not a currency split, but rather a protocol upgrade by means of a sidechain. I'll post more about it in the 'Future of Friecoin' thread. Actually it occurs to me that you probably mean "currency split" in the same sense as "stock split" -- for each freicoin you own now, you get two on the other side. Yes, that is approximately what I am suggesting. To be clear, it is different from the type of "currency split" you see going on right now with BTC/BCH, which is why I was confused at first.

Rik8119, well Freicoin has -5% demurrage, which is fixed, but also a constant subsidy that is equal to +5% per year. So the amount being created right now exactly counter-balances the amount being destroyed by demurrage. meaning there is zero net inflation. However that is only true if you consider the Freicoin Foundation funds as part of that calculation -- otherwise there is something like 14% inflation per year at this time. Even if the foundation funds were destroyed there would continue to be inflation for decades until the net usable issuance once again approximates 100M coins, at which point demurrage would equal subsidy.

As Jorge points out in the beginning of this thread, this can be fixed by either distributing or issuing the coins more quickly (rightly rejected), or by doing a soft-fork to lower the subsidy. However that approach changes mining incentives and carries with it significant risks. A better approach, I argue, is to tie the subsidy fix to an opt-in protocol upgrade package. This gives us more options and lets us decouple the two issues of the future of the foundation and what to do about the resulting subsidy/demurage mismatch.

Wow, what a thread!

Jorge told me of his intention to post this, and I told him that although I had some feedback to give he should post anyway and I will provide my own thoughts as a comment. Now that I've wrapped up being a block chain trainer at the BC-2 workshop in Japan, I actually have time to do so.

First, I'm very thankful to see that most of the community are of the same mind regarding this issue (also, hi galambo!). The foundation was created for the purpose of solving a problem we perceived with the two competing requirements of the distribution mechanism: we wanted it to be fast so that the monetary base stabilized quickly and we could test Gesell's theory of money, but we also wanted to avoid plausible allegations of pre-mining. Sadly we must recognize that we accomplished neither -- the inflation rate of freicoin is unclear so long as the future of the foundation funds is undetermined, and the "foundation" has been misconstrued by many to resemble other foundations with more centralized purposes.

Really all we did was punt the issue. We hoped that we could come up with another fair, decentralized mechanism for distribution of the foundation funds. In reality that task proved nearly impossible, and certainly not doable with the manpower available. Republicoin remains on the drawing board as we were unable to come up with a suitably decentralized version that didn't compromise privacy and fungibility goals, let alone implement any of the half-working solutions. The charity matching program is technically still live but hasn't been operational as the backend suffers some major exploitable flaws.

So reason number 1 to kill the foundation is that it seems we are unable to meet the technical goals for distribution, and arguably we should all prefer to see those funds destroyed in a publicly verifiable way rather than compromise on those ideals and do something that could be construed as an actual pre-mine.

The second reason is regulatory.

Coin Center released in 2016 a good legal brief for deciding whether a cryptocurrency offering should be considered a security or not, which has grave regulatory implications. You can read the report here:

https://coincenter.org/entry/is-bitcoin-a-security

https://coincenter.org/entry/framework-for-securities-regulation-of-cryptocurrencies

That's how people in bitcoin space were hoping the issue would be handled. Just a few weeks ago any uncertainty about what regulators are thinking was cleared up when the SEC announced that they would use basically the same rules for deciding whether a crypto token is an unlicensed security offering. Notably they say that the DAO was a security, and presumably so was most if not all of the ICOs. You can read that report here:

https://www.sec.gov/news/press-release/2017-131

What would it mean if the SEC decided that freicoin was a securities offering? Well, in the frightening worst case it could mean that those responsible for creating the currency (gulp, me and a few others) could be forced to pay exorbitant fines AND go to federal prison for decades of our lives, as well as prevent us from ever working in the financial industry ever again. Conceivably it might not even matter if those involved are US persons given the way the US uses extradition treaties to enforce its laws around the globe. So please, let's take this seriously.

(In case I frightened anyone too much, note that the SEC decided not to take action on the DAO, presumably because the regulatory situation was not clear at the time it was created. Now there's no excuse. The legal advice I received is that as long as we take proactive action to to make maximally sure we're in complicance, we should be okay. So as long as we take the actions I mention here, I'm still in this for the long run )

The gold standard for whether an offering is a security is the Howey test. Quoting the Coin Center page: "An investment contract for purposes of the Securities Act means a contract, transaction or scheme whereby a person . . .

•   invests his money in
•   a common enterprise and is led to
•   expect profits
•   solely from the efforts of the promoter or a third party

Invests his money? Well people can buy freicoin on exchanges, does that count? Unclear. Certainly it would be bad if the Foundation (a kinda-sortof pre-mine) sold its coins to investors. If this were a regular proof-of-work mined only currency the answer would be no, but honestly the existence of the foundation complicates this in hard to determine ways. Whether freicoin meets this test is really up to the prejudices of the SEC, which I have no insight into. So let's assume yes, but things would be much better if the foundation ceased to exist and the coins it managed were destroyed (this precludes, for example, directly giving out the coins to existing holders).

A common enterprise? We're all here for demurrage money, right? Check.

Expects profits? Let's be honest, everyone expects the freicoin price to rise if/when it sees significant usage. I would like to say that as demurrage money the freicoin price will be stable and only used as a medium of exchange. But while that might happen in the future, we are not there yet. Someone investing in freicoin today is probably expecting a return, not actually using it themselves (yet).

Finally, expects those profits to come solely from the efforts of the promoter or a third party. Here again the foundation rears its ugly head. I'm happy to say that since freicoin was created we ALWAYS had an idea of the foundation only being involved in the initial issuance and then disbanding, and not doing anything else. The foundation doesn't even pay for the official freicoin website -- I pay out of pocket for those negligible hosting costs. However the SEC will be judging not based on what the foundation does but what a reasonable investor might think they do. And I'm sorry to say there's a lot of misinformation out there. Would a reasonable investor think that the Freicoin Foundation is like, say, the Litecoin Foundation or Ethereum Foundation, both of which pay for both development work and promotion of the coin itself? I don't know.. and that worries me.

Both points (1) and (4) would be made SIGNIFICANTLY clearer if the foundation was unequivocally disbanded, and the funds it controls destroyed.

I think there are some concessions that can be reasonably made. Namely we promised 1:1 matching of charitable contributions, which we haven't delivered on. In fact, those donations are still sitting on keys controlled by the foundation. We can forward those funds and do a retroactive 1:1 matching, before destroying the rest of the coins.

The foundation has a few non-charitable causes listed on it. We'll have to figure out what to do with those. The original donations can obviously be forwarded, but I'm not sure we can reasonably match the contribution. We'll also have to figure out what we do with donations to the foundation itself -- both foundation and the freimarkets bounty fund.

I think we CAN'T do anything like distribute the coins to current holders. Destroying the coins is the same economically anyway, and much clearer intent in the eyes of regulators.

Finally, my own vote is for option number 1 (sorry!), but with a twist. I will separately be making some posts on this forum about my intention to release an elements-derived sidechain to freicoin that is proof-of-work mined (Rik, this addresses your comment from page 2, but is off topic for this thread). It is possible that we could, for example, allow pegs into this sidechain to be doubled in quantity 2:1 so that up to 50M freicoins can be moved from the old chain to the new chain, resulting in 100M on the other side. The new chain would also have its own subsidy so, if all goes well, there is a period of coexistence where both chains are used, until the peg pool is exhausted and the old chain is archived. We can quibble the details, but something LIKE this would allow us to maintain 100M total freicoins and achieve full issuance more quickly without the complications of a miner-incentive-reducing soft-fork.

In any case, the option 4 is just option 1 followed by a soft-fork. So can we at least say that we are in agreement to finish the donation matching, destroy the funds, then start a conversation about the best way to handle the mis-match between subsidy, demurrage, and the total monetary base? Even if you guys want to go with the soft-fork, which I respect, the coins can be destroyed first whereas the soft-fork requries some development and testing.

???? ???? ???? ????

Yeah!!!

The current block height is 160755. By my calculation that's 3,085 blocks (about 3 weeks) until the initial issuance of 100M freicoins is fully played out. That is also when the coinbase blocks stop including foundation outputs.

Time to organize a celebration?

Reminder to miners to please upgrade... the 144-block window currently shows 75% have upgraded, but 2016-block window hovers at about 50%. I suspect the difference is multi-pool related although further analysis is required. In any case there does appear to be some long-term freicoin miners that have not upgraded, enough to keep us from activating the BIP 66 and input-truncation forks.

Also, if anyone has contacts with exchanges that host Freicoin, getting their daemons upgraded should be a priority.

There's a new release of the Freicoin client for Linux and Windows, version 0.8.6-2, hosted on the official website:

http://freico.in/download/

Note that there was a problem in trying to update the Ubuntu PPA, which I am working to resolve. The recommended solution is to use the gitian-built, statically linked binaries on the website.

The new release contains TWO soft-forks. One is a security update to the consensus rules documented in BIP 66 (strict DER signatures). The other is freicoin-specific: truncation of input amounts. This greatly simplifies the code diff between Bitcoin and Freicoin, making the client easier to maintain and hopefully allow us to bring back regular supported releases in a cadence matching Bitcoin Core: Freicoin releases shortly after Bitcoin's.

The next release of Freicoin will be based on Bitcoin 0.13.x, and is currently being worked on. Because of the changes in the accounting rules, a 0.13 release will be conditional on successful activation of the input truncation soft-fork. So miners & mining pools, please upgrade!

My only question really is that the 80% of foundation funds not distributed by December 2015 will they be 'destroyed' as per the original commitment?

 

As it was stated clearly initially that the 80% was to be redistributed completely within 3 years of launch and if that failed to happen the funds would be simply destroyed if I am not mistaken. 

You are mistaken. I'm sorry but that was never the plan.

Republicoin solves a problem that doesn't yet exist -- what to do when the subsidy is so large in real dollars that it more than secures the network and then some. Republicoin is an unfinished outline of a solution for how to spend that "and then some" in a socially beneficial way.

It's a problem I would like to have. But doing any more than theorizing a this stage is frankly putting the cart before the horse or counting your chickens before they hatch -- pick your metaphor. We don't know what the long-term value of 1 freicoin will be, so it's kinda hard to guess how much security 97 freicoins per block will provide. If freicoin really does have a very high velocity, as expected, then maybe it will be too little!

I will note in passing that the situation has improved somewhat in terms of the viability of republicoin. We had previously considered proof-of-stake voting schemes, although these suffer from the nothing-at-stake problem (being able to vote for multiple proposals) and miner censorship of the vote. By instead making votes part of the transaction format and weighting votes by freicoin-days-destroyed, it may be possible to at least have an economic cost to miner censorship. It's not a complete solution as of yet, but it is outline of something better.

Regarding the Freicoin Alliance, perhaps consider breaking up your projects and soliciting donations separately for each? This is not ideal and I would have to confer with Jorge and r000n to see if this would be acceptable, but if it is indeed the case that the donations are mostly going through Freicoin Alliance then it would make sense.

Regarding voting, that could be done in a rudimentary way using signed messages. I guess I would have to delve deep and understand the requirements better before giving advice (sorry it's late here and I've caught some sort of fever that is making it hard to concentrate).

If you came here expecting an authoritative declaration of where Freicoin is headed, prepare to be disappointed. Freicoin is not led from above, it is and must be organized from the grassroots--the user base. It is you that sets the direction of Freicoin and my intention in posting this is to rekindle an open discussion about where freicoin is headed, and what our priorities should be.

Updated Freicoin Core

There are a few consensus bugs that freicoin is currently exposed to. The most egregious bugs can be fixed by backporting fixes to the 0.8 branch and doing an emergency release. This is presently Jorge and my highest priority, and you should expect a soft-fork release implementing these fixes very soon.

There are a lot of other security bug fixes that are not so easily back ported however, as well as valuable new features and performance updates in the latest Bitcoin Core releases. It is our intention to finish the 0.9 port, then move quite rapidly to 0.10 and then 0.11, and having Freicoin keep up with the Bitcoin release schedule thereafter.

There was a while in the past where we kept up a good release cadence, sometimes having freicoin releases the very same day as bitcoin. While I accept responsibility for letting this slide over the past 12 months, one of the difficulties we encountered while we were keeping up was a lack of testing by the freicoin community of our release candidates. It would be absolutely irresponsible of us to do an official release from a code base that had not been adequately tested by multiple individuals in a variety of deployment environments. This is what held up the 0.9 release and what will continue to hold up future releases of Freicoin Core.

We need testers. Please consider volunteering a few hours of your time around each release downloading & building the Freicoin Core wallet, and taking it for a test drive. This is a way in which anyone can give back to freicoin development without requiring any specific skillset.

New features

As you may know, a good chunk of the code Jorge and I work with on a daily basis is now open-source as part of the sidechain elements project. We have explicit permission from our employer baked into our work agreements to allow us to port these features to freicoin as they are released. Many of the features that have already been released we feel freicoin would benefit greatly from, and intend to integrate into freicoin in due time. These features include:

• Lock-time improvements. Written by Peter Todd and yours truly, these are soft-fork enhancements which improve the utility of lock-time (allowing trustless micropayment channel setup, for example). These are soft-fork changes and ready to deploy today, although they are presently receiving review by the bitcoin community.
   
• Native assets. Also known as: freimarkets. Adds explicit asset coloring and corresponding accounting rules, and makes the transaction format more expressive so as to support pre-signed offers and other financial contracts necessary for a peer-to-peer exchange. Only the most basic version is implemented so far, and it is a hard-fork change.
   
• Segregated witness. Eliminates malleability concerns entirely, as well as yields significant performance enhancements to syncing the historical block chain. This is a hard-fork change, and currently undergoing minor improvements.
   
• Confidential transactions. Allows selective disclosure of an output's value. Observers watching the chain have limited information about the values being transacted, thereby achieving an increased level of privacy. This is a hard-fork change, and currently undergoing major improvements.
   
• A non-disclosed method for non-interactive CoinJoin. This is a hard-fork change, and presently still on the drawing board. More details to emerge as this is released as part of sidechain elements.

There are other features being worked on for the sidechain elements project we feel freicoin would benefit greatly from. For example, script replacement. However these are large multi-year projects and I'm confining this update to things which could be deployed to freicoin in the relatively short term.

Merged mining

The freicoin initial issuance is almost paid out. At some point after the initial issuance is complete, we would like to hard-fork freicoin to allow an improved form of merged mining -- allowing a single proof of work to secure both bitcoin and freicoin at the same time. This will at long last eliminate the difficulties we have had in building and maintaining a stable and secure hash rate.

This will unfortunately have a devastating effect on the grassroots freicoin mining community that presently exists. Although investments in mining ASICs will not be recoverable, it may be possible to restart, for a while, a "GPU mining" initiative by using foundation funds to pay for work performed for reputable scientific distributed compute project, e.g. Folding@Home. More on that in a moment.

The Foundation

Finally, the contentious point that most people want clarity on. What is going to happen with the foundation funds, now that they are almost entirely generated and almost entirely undistributed? And once they are distributed, what is the plan for the foundation afterwards? Let's take these in turn, starting with what has gone before:

The past

When it was first decided that there would be a foundation to distribute a portion of the initial issuance, there was no plan for distributing the coins. Rather, there was a preference to NOT distribute the coins entirely to a subset of early adopters via mining, and a requirement that these funds be distributed in a decentralized way, although no decentralized alternatives to mining had been proposed yet. Ultimately two fair decentralized distribution mechanisms were discovered, and work has begun to start issuance via those methods.

The first approved distribution mechanism was the community and non-profit donation matching program presently being run on freicoin.org. This achieves decentralization because donors select the recipients of foundation funds via their own contributions. It however requires some oversight to prevent emptying of the foundation funds by a bad actor. So far approximately 150k freicoins have been distributed via the donation matching program, and a further 900k is obligated. However the obligated funds have been delayed until such time as the donation matching program can be re-implemented to prevent theft of Foundation funds.

The second approved distribution mechanism was the payment of opt-in participants of a volunteer-compute projects for the social good, such as Folding@Home. Participants would opt-in to running a daemon on their computer which injects payment invoices into the completed work units submitted to the @Home project. Foundation servers then scan these work units for invoices and pay out to the addresses contained within in proportion to the points earned by the submitting user over some interval. This has not been deployed yet simply due to time constraints in getting the code written.

The present

There is need for a programmer to re-write the donation matching script. This requires only rudimentary computer science knowledge. If you or someone you know meets these qualifications and would like to contribute their time (unpaid), please let me know.

There is a need for a programmer to write the @Home issuance mechanism. This requires a moderate amount of computer science knowledge, including an ability to scrape and parse information from HTML sources. If you or someone you know meets these qualifications and would like to contribute their time (unpaid), please let me know.

We are open to approving new distribution mechanisms in the future, but the mechanism for distribution must be fair and decentralized. Alternatively, we may approve a series of prizes for the funds, but only if awarding of the prize purse is done in a provably fair and unbiased manor, e.g. by smart contract.

The future

There seems to be two major concerns regarding the future of the Freicoin Foundation:

1. What happens at the end of the 3-year issuance period? Nothing out of the ordinary. It was a hope, but never an expectation that the foundation funds would be fully issued during this time period. The foundation will continue to operate as long as funds are available.
    
2. What happens when the foundation funds are exhausted? The foundation will cease to exist, having completed its only purpose of carrying out its portion of the initial issuance. There is no expectation that the foundation will continue to exist as an active entity after its original goals are achieved.

Conclusion

Freicoin belongs to the people who use it. Jorge and I have some ideas for where we would like the project to go -- expanding scope, and pulling in new users. But it is you, the people using freicoin, who hold the ultimate authority over its direction. I open the floor for discussion.

So Black Arrow finally, finally is ready to ships machines 1 & 2. These were originally slated to be hosted with Joe, and they're asking for updated shipping addresses. Unfortunately I lack any kind of hosting capability myself. Does anyone in FA have room for two units? Mollycat, do you have extra rack space where you put unit #3?

1. How might this affect current exchanges?

2. How should we in the FA proceed with things like the Android
based Wallet?

3. Do we need to wait for sidechains if we are trying to get
bootstrapped applications that might need new coding for
sidechains?

4. How might this affect current service providers like
cointopay does this make them obsolete or will they have to work on a
new adaptation to sidechains when they are live?

5. How can we help support bootstrapping before during and
after the implementation of sidechains? Meaning what areas should we
focus on?