jtimon

I'm sorry for not having responded for so much time.

I still need to read the whole thread, but at a glance it seems clear that we can safely discard option 3.

I need to read all the responses, thank you everyone for responding. But it seems option 4 isn't very liked either.

And mark proposes another option related with his proposal. But I must admit I haven't fully reviewed and thus I don't fully understand his proposal yet. Mark, sorry one more time about that, I did promise you to do it.

Having all the foundation funds in one output is fine with me.

After all, if mark tries to spend them we will all see. And if someone else has access to them and tries to spend them we will see that too. Not that I have looked, I should. It also simplifies things for whatever we're going to do next.  

So re-summarizing (and before reading it all, sorry again for the things I may be missing), I think we now have these 3 main options:

A] Send all the funds to a single OP_RETURN output to destroy them (see option 1 in OP).

B] Send the funds to many OP_TRUE outputs with different locktimes that miners will be easily able to claim. (see option 2 in the OP).

Let's say, just to distribute all the funds in the next 2 years, but there are many options here.

C] (requires softfork) mark's proposal about forward blocks.

I'll try to get more involved again, sorry, everyone.

My preference is still option B.

B.1) I propose constant distribution per block for simplicity.

B.2) But doing a linear reduction like in the initial 3 years for the initial 20% shouldn't be that hard, so that we avoid a theoretically possible hashrate crash when that constant temporary subsidy goes away in the b.1 case.

But then again I haven't written the code to create the tx or set of txs needed for that. 

Even though I don't understand option C well enough, I think it would be good to separate the end of the foundation from any softfork that may come afterwards.

I feel it will be simpler to understand for everyone else too if the two events are clearly separated.

I don't doubt Mark's forward blocks proposal has many merits, but I feel it's a very big step.

Any such step should be taken on solid ground, and I don't think the foundation being in the air is near that ideal solid ground.

Just my opinion, obviously.

 

 

 

 

So, regarding releases...should we keep working on 0.9 for the next release and also start working on a 0.15 rebase for the next after that one?
 

Well, first of all if one chain is planned to be abandoned after some 1wp period, some coins will get lost there.
I don't see the point in doing any kind of peg between 2 currencies with different subsidies (money creation) in different chains. The 2:1 up to 50 M also seems pointless.
I don't think another chain helps with the foundation problem in any way.
Apart from that, I would prefer a hf to elements features or a spin-off (if we really want a new genesis block) than a one way peg. But I guess we can leave that for other threads.

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

This sounds, in principle, as a very bad idea to me.

My intention is not to "abandon the coin and let it die" but that doesn't mean maaku, me or any other voluntary should be bullied for using (or not) their time as a voluntary however they want. 
Please, @Arcurus stop telling other volunteers how they should spend their time. You are free to spend your own time however you want. When things don't happen as fast as you wanted them to happen (or just don't happen at all), don't blame other volunteers for not having done them: blame yourself for not having done more to make them happen.

@Bicknellski volunteers that are developers don't have special obligations or privileges. Here there's no ICO in which users paid developers like in eth: eth and freicoin communities simply cannot be compared in this sense. Please stop talking as if @Mark Friedenbach me or anyone else owed you something just because you are a user. I'm a user too. Just because I learned how to program that doesn't make me your slave or anyone else's.

Please, save your "developers should do X or focus on Y", "the community should focus on X", etc. In my experience that doesn't help build a healthy community of volunteers, it does pretty much the opposite. You will focus on whatever interests you the most and everyone else will do the same.

We can discuss potential future roadmaps in other threads, but this is about putting an end to the foundation.
So back to the topic at hand...

Yes, as said in the opening post, I think the promised 100% matching should be done before putting an end to the foundation.

Regarding the softfork to limit the quantity that the foundation can issue:

1) There's no need to do that at the consensus level if the foundation is still centralized.

2) It doesn't put an end to the centralized foundation.

I'm surprised that people don't like 2 and I'm not sure I understand the reasons, but it seems I'm kind of alone having that as a favorite.
I guess my preferred order is: 2 > 4 > 1 > 3.

It is to be expected that with a higher reward we just get an increase in hashrate and difficulty, and thus an increase in security (which currently isn't great due to the tiny reward), but not necessarily to miners' profits.
This may have a temporary effect on the price, but I don't think it will be greater than with option 3. Option 3 also doubles the utxo size (well, more or less, discounting reused addresses).

Again, option 4 (reducing block subsidy and thus the total 100 M supply) is not a hardfork, but a softfork.
 

> doesn't sound that great to me. its basically Bitcoin with demurrage for eternity to miners what @jtimon suggested.

Yes, that was basically freicoin's design from the beginning. The foundation was a later mistake.

> i strongly oppose not to look into proof of stake security

I did look into pos, and I think it's flawed. But you are free to keep looking into it.

> to the soft fork, that could be easy to implement, just add one address where some part of the block reward goes if less than 100K coins are on that and give control of the address to someone who does the job of distributing them. later we can decentralize it.

Isn't that what the foundation is currently supposed to do?

> simply destroy the coins seems up to now the best solution for the foundation.

You mean option 1 or option 4?

> simply out of curiosity, where did the community fail in distributing the coins?

Well, the coins are not being distributed. There's no software to do so automatically (we didn't moved from 10% to 100%). And that's only for the matching program, the community also didn't developed any other distribution program.

> i dont think that neither @jtimon or marc will even look into proof of stake. 

We did. And I'm starting to get tired of you bringing up the subject on every topic, even if it doesn't have anything to do with pos like this one. If you care about pos more than you care about demurrage I think you confused freicoin with ppcoin.

> by the way if you want to know how a distributed foundation can be implemented in a soft fork, just look how dash does it. yes the technology is out there since years and functioning very we

I think dash is deeply broken tech, it is very frustrating that you keep comparing bitcoin and freicoin to it all the time. You are more than welcome to implement your own coin with dash "features" and with demurrage. I'm not interested. Regarding distributing coins with a sf/hf, that's basically what republicoin was about. But distributing it on-chain is not easier than distributing it through a centralized foundation, which we're failing at. You are more than welcomed to write the code. Until then, I think using demurrage as mining subsidy is the simplest and more reasonable option.

@Rik8119 what you suggest is option 4 and it's a sf, not a hf. Still, it's the only option that requires a consensus change. And IMO it's dubious that it has any important advantage over the other options. I still don't think I understand the complains against option 2, to be honest. The funds are currently "going to miners" just by leaving them with the foundation and they would also go to miners with option 1, only slower (thus having both inflation plus demurrage for much longer).

@Mark Friedenbachhas access to the keys, I don't see how "the users for github" are relevant.

> So when will all this happen?

Not before we decide what to do.

> So what is your vision for the coin moving forward Developers?

My priority regarding Freicoin is starting to do rebases much faster and continuously, getting all the new improvements, bugfixes and features.
As for new consensus changes features, apart from those included in more modern versions of bitcoin (cltv[bip65], csv[bip68/bip112], segwit[bip141]), it would be nice to get features from https://elementsproject.org/ which now also rebases periodically. Specially I would like to have confidential transactions https://elementsproject.org/elements/confidential-transactions/ and confidential assets: https://elementsproject.org/elements/asset-issuance/ This is similar to freimarkets' basic asset issuance but with much better privacy. But that requires a hardfork, so it strongly depends on support from the community. There's also some incentive problems with the utxo, but I think we can solve them.
In general, that's my basic plan for Freicoin development: rebase and get new features from elements and bitcoin.

I'm also working on a block explorer for bitcoin, elements and liquid that I would like to adapt to freicoin as well.
But of course other people can work on other things.

In any case, this is rather orthogonal to the foundation's funds. So please, let's try to stay on topic.
New developments, new webs and potential consensus changes are all fine to discuss, but I don't think they are directly related to the question at hand, which is admitting we have failed as a community (and as devs) with the foundation and non-mining distribution, put an end to it and move on to other things.
 

>  with the  BTC from the ico, you pay the developers to work full-time on FRC and do promotion

Which developers are interested in doing that?
I'm not interested in beig paid by an ICO and I'm pretty sure maaku doesn't want that either.

> Certainly, you know the issues surrounding coming regulation better than most. 

No, actually, I don't. But I never wanted to be paid from money collected through an "ICO" precisely because I don't know and I don't want to find out the hard way.
 

Re: ICO: no, as said icos are part of the motivation for destroying the foundation. You make an ico of frc for btc and then what you do with the btc? 

> a softfork that makes sure that some part of the block reward is used for Freicoin related projects. 

If we had the technology to do that we wouldn't need to destroy the foundation's coins. But we don't.

> that demurrage should be drawn from there only and not from speculators/normal wallets. 

So basically remove the demurrage feature that inspired freicoin in the first place and makes it unique. I strongly oppose this.

> proof of stake

Strongly oppose.

> The coins should be destroyed, and that it takes time to reach 100 mil is good.

Good for what? The initial plan was to have 0% inflation on top of the 5% demurrage in only 3 years.

> To be honest i think 100 mil is too much either way and its not a good number.

There's no number that's better than another. 100 M is more or less arbitrary, but less than 21 M.

> i don't see how higher mining rewards will benefit the coin, more coins means simply less price per coin.

In all the options is the same amount (100 M) except for option 4.

Thanks everyone for sharing your views!

> Woergl f.e. was the most successful freigeld currency and they used it to pay for social infrastructure. And IMHO it is the only reasonable purpose to redistribute money to the poor.

The purpose of freigeld is not to redistribute money to the poor, but rather remove the existence of poverty under the assumption that is caused by chronic interest and cyclic monetary velocity.

> option 2 is not fair to investors.

I don't see why not. The coins were planned to be put in circulation either way.
As "investor" I don't consider it unfair. 

If I was to re-design Freicoin from the beginning I would change some small things, but it wouldn't look like this proposal at all.

I haven't read the whole post but I must say it is unlikely I will ever use, support or contribute in any way to an altcoin based on PoS. I also think that 1 min blocks and moving from demurrage to inflation are bad ideas.
Since it seems to be based on different ideas and priorities I ask that please don't call this altcoin freicoin 2 and call it something else instead.
 

> i like freicoin but I don't see movements. When starts the party? anothers coins with + 3000%.

Forget about the price. Freicoin is not about speculation.

I don't have a node now (shame on me, I wasn't able to compile the other day).
From what Rik8119 says, it seems that the longest chain is invalid, because the blocks have nVersion=2

> I can only run version x.8.3. 

There's your problem then, once bip66 was activated, all miners need to validate it and produce nVersion=3 blocks.
From what it's in the release notes you need 0.8.6.2, see https://github.com/freicoin/freicoin/commit/808ee0ecab1e075c0835e74cd85627d3e5b1dd1d
 

The last sentence of the paper: "We showed that by depending only on resources within the system, proof of stake cannot be used to form a distributed consensus, since it depends on the very history it is trying to form to enforce loss of value."

That doesn't mean that proof of stake cannot be useful for other things different from securing the chain (for example, republicoin).

About rebasing...it's not just about getting "neat features" from bitcoin upstream. It is also about getting important security and privacy improvements. For circulation, we have demurrage: the donation matching is only about initial distribution (instead of using all the seigniorage as subsidies to miners), and also about experimenting on ways to distribute the 5% perpetual seigniorage (that comes from the demurrage) in case that turns out to be too much subsidy for miners. I mean, if matched donations program can also help with development, adoption, etc. why not use it like we're doing? But the initial concern was not giving it all to miners as subsidies.

1) Yes, having the android wallet in freico.in downloads is probably a good idea. Please someone code the change (should be really simple) for https://github.com/freicoin/freico.in

2) freicoin.org is managed by Roman Mindalev (r000n). Not sure what bitcointalk.org has to do with this... I think this forum is nice for the main point of communication, but it would be nice to use the mailing list for developement and testing.

 

3) It would be as simple as adding a 0 if it wasn't because we want to apply it retroactively (ie the donations that where matched only with 10% will be completed with the remaining 90%).

4) Let's focus on distributing the foundation funds first and then about taking a part of the perpetual 5% for miners and use it somehow else in a p2p fashion (republicoin): the latter is much more difficult.

About "a common vision", the fact is that different volunteers are interested in different things. I don't think that can (or should) be "fixed".
I think it's very hard to agree on what we will do after some experiments "have gone well" until we actually see the results of the experiments.
I think republicoin is interesting but I see it as a much longer term thing (after distributing the foundation funds, and after adding issued assets and stuff like that).

I think using proof of stake to secure the blockchain is a terrible idea and it will introduce more security problems than it will "solve", see https://download.wpsoftware.net/bitcoin/pos.pdf
Of course, the people using proof of stake to promote their altcoins with fallacious arguments will disagree (just like litecoin users used to disagree on Scrypt being implementable on GPGPU and then on being implementable as an ASIC)...

with a strong Bitcoin in the back maybe we can get some traction again. To be the first o start, is there anything i can do, testing etc.?

Hello Rik!

We desperately need help with testing.

Development and trouble-shooting things are usually discussed on IRC (server: freenode channel: #freicoin )

We don't really use it much, but there's also a mailing list for announcements that I think we could recycle into a dev mailing list: https://groups.google.com/forum/#!forum/freicoin

We used to use http://freicoin.freeforums.org/technical-f17.htmlfor that, but we prefer to use the freicoin alliance forums now for several reasons.

I'm sorry that I cannot be very responsive on the alliance forums, but I now would like to focus on development only. I will probably be more responsive on IRC or the mailing list - specially if we change it from announcements [which can be done here] to development only), but I try to catch up here from time to time (I still always have too many unread stuff). 

 

Anyway, where to start?

We probably should have a developer/tester guide analogous to https://bitcoin.org/en/developmentin freico.in but something you can do is just clone the main branch, which contains  0.8.3-1 (the "officially deployed" version):

https://github.com/freicoin/freicoin/

Compile it. Test it (maybe synchronize on main and/or testnet, confirm some transactions on regtest and/or testnet?)

But we're really behind when it comes to rebasing on top of the main bitcoin codebase (and getting its improvements and new features).

So it would be much more useful if you compiled and tested 0.9, the next version, which has been coded for a long time, but hasn't been released yet due to lack of testing. Mark and I believe we have most of the work to rebase to 0.10 done as well, but it depends on the validity of 0.9.

Some things we're re-architected from 0.9 to 0.10 (more risk), but we believe this will simplify rebases for future versions (ie 0.11 and 0.12 for now).

I'm having problems compiling 0.9 right now myself, so if you have the time and the will to put together a document with instructions for "how to test the next rebased version of freicoin" from your experience, that would definitely be very useful.

You will get help on #freicoin or the mailing list for any problems you may encounter in the process of testing (either testing 0.8 or 0.9): you want to test and we love you for it.

 

How far is the sidechain project?

I'm really excited with the assets feature/element that follows the basic design in freimarkets and will be part of elements/beta-0.12. Currently the branch is in https://github.com/ElementsProject/elements/commits/alpha-0.10-multi-asset being reviewed and tested by other members of the team

as part of the elements beta development cycle (although external review and testing is welcomed too).

It is coded on top of alpha and therefore it's compatible with

confidential transactions, but it changes the transaction

serialization and therefore it's incompatible with alpha itself (it's

a hardfork).

You can only test it in regtest mode.

The wallet functionality has not been adapted to handle multiple

assets, but you can use the rawtransaction RPCs or alpha-tx.

You can also ask on the sidechains mailing list:

https://lists.linuxfoundation.org/mailman/listinfo/sidechains-dev

Thanks for your interest!

If the community wants, we can eventually deploy these are more features from elements in a hardfork to freicoin (the community seemed to liked at least the features described in freimarkets), but we first have to rebase to 0.10 and then to 0.12!

Re Foundation:

Although I'm sad for not having the time I used to have to develop and promote freicoin, I am very glad that the community has grown and has taken over some things I used to spend a lot of time on, like moderating the old forums (thanks freicoin alliance!) or make the freicoin foundation still interesting (thanks freicoin allience and specially Arcurus!). Then again, I'm sad that we're behind on development there too, since https://github.com/maaku/coinmatch/commits/mastershould have been adapted/replaced to support 100% donation matching retroactively instead of the initial choice 10% long ago (at the same time I'm glad we're regretting having started with 10% instead of regretting a start on 100%, plus the price was and still is unpredictable: better safe than sorry). Anyway, I don't think anybody has complained about 10% or 100% donation matching being too much or about applying the change retroactively (not to discourage people to donate now), rather about the change from 10% to 100% not happening. So it's just a matter of someone adapting or replacing coinmatch. And of course continue working on reucruiting more non-profits and projects to receive the matched donations like the basic income experiments.

I agree to that.

Would be good to bring the donation matching to run.

Would also be great if we can also distribute some coins though voting with coins.

 

And as said, good to outline an clear vision for Freicoin and the Coin Issuing.

Yes, voting with coins could be a first prototype for a future "republicoin" (even if t's centralized at first) in case we need it in the future.

Of course, yes, we should fix https://github.com/maaku/coinmatchto retroactively give a higher percentage than 10% first (which is also much simpler).

The voluntary computation subsidy (ala curecoin) should be simpler than a republicoin draft as well.

Unfortunately we don't have that many developers around to do all these things and my time has been more focused lately on bitcoin development (which will directly benefit Freicoin as we rebase), sidechains developement (specifically freimarkets features that will be integrated in Freicoin) and some rebasing work from 0.9 to 0.10.

We haven't released Freicoin-0.9 because it hasn't been tested, please help test: https://github.com/freicoin/freicoin/commits/0.9

We also need to backport BIP66 back to 0.9 and 0.8. It should be relatively simple to make, but there's a potential attack that could be done against Freicoin while we don't deploy the BIP66 softfork.

I'm personally much more worried about that last thing than about the foundation coins being demurraged instead of distributed to the matched donations and other mechanisms but if anyone else wants to code (or pay someone else to code) these other things, they are certainly important too (the fact that the foundation is going to run that code doesn't mean that it can't be written by someone else).

The rebasing work it's very important too. For example, the user experience will be much more pleasant after rebasing on top of 0.10 with headers first. Wallet developers would benefit from a libfreicoinconsensus as well.

0.11 has pruning to not require that much storage space, etc. There's many Bitcoin improvements we're not enjoying yet because we've not rebased (and because what is rebased [ie 0.9] is not tested).

 

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.

 

Sounds reasonable to me. I'm not even sure why you think it's not ideal, I think I prefer separated projects so can donors have more freedom to chose.

 

@Bicknellski , the goal of distributing everything in 3 years was ambitious and we admittedly failed at it. Although that doesn't necessarily mean we have to destroy the coins, destroying the remaining foundation coins is always a possibility at any point if we think it's necessary. In fact, miners could do it against the freicoin foundation wishes with a relatively simple softfork (spending from foundation addresses is no longer permitted after the softfork).

The reason why the subsidy only lasted 3 years (and why we wanted to distribute all foundation funds in 3 years) was to reduce inflation to 0 as soon as possible leaving only the 5% demurrage (currently freicoin is way less inflationary than bitcoin, even if you count the 5% demurrage as inflation).

1) If we destroy those funds it will take much longer to get to 0% inflation.

Another possibility maaku came up with the other day would be to distribute all remaining coins proportionally between all current holders (leaving them with the same % of the total issued coins, so it would be perfectly fair).

This wouldn't need a softfork (although doing it with a hardfork would have some advantages over doing it with the foundation's wallet directly) and it also lacks the disadvantage 1.

 

A third possibility would be to turn them back into mining subsidies (say, to be fully distributed to miners in the next 3 years).

 

All these actions would share the following disadvantages though:

 

2) We lose the opportunity to make more good with the matching donations program (specially if freicoin rises in price).

3) We lose the opportunity to subsidize folding@home (ala curecoin), which would be a good way to not harm current GPU miners that much when we move to merge mining.

 

My personal preference would be not to take any of these actions (for now, maybe later I change my mind if we take too long to reach 0% inflation) and just continue with the matching donations and also implement the folding@home subsidy program, but if I have to chose between one of them I would clearly chose to second option.

It's up to the whole community though, not just me or maaku.

Whatever we do should ideally be uncontroversial among the community.

Bravo Arcurus!
The unit of the future is a global index rather than an actual currency. And Freicoin doesn't need to be a good unit of account to be a great medium of exchange and cheap currency in lending terms.
We've talked about similar concepts before under names like GRU (Global Reference Unit) or TRU (Trade Reference Unit, inspired in Bernard Lietaer's Terra or Trade Reference Currency).
I talked to Thomas Greco (http://en.wikipedia.org/wiki/Thomas_H._Greco,_Jr. ) about this and he had the same idea long ago, and tried to convince Lietaer that an index rather than an actual "backed" currency it's what's needed.
An index can contain any number of commodities or even services in its basket because you don't have to store them to "back" a currency.
Given a basket formula and a set of markets APIs that the formula is based on, it is quite trivial to create a converter from TRU to any actual currency like FRC, BTC, USD, EUR, etc.
So the challenge is to actually chose the markets and their weighs in the TRU formula.
In FreiHours' case, there's only one "market" you have to look at. I assume you're thinking about using the federal reserve official inflation statistics. Many people claim they're quite manipulated (see http://www.shadowstats.com/alternate_data/inflation-chartsfor example), but that would be something simple to start the experiment and it is still more stable than the USD itself by definition.
We could make a bounty for the converter once the the FreiHours index is more formally defined.

Thanks, I edited the email and validated the organization. I'm not sure about the description, but you can edit the description if you change your mind.

Just checking here before validating the freicoin alliance to receive donations as nonprofit. 
Is everything correct?

The Bitcoin address is just in case people donate bitcoins to you (by mistake): we would just forward them to the bitcoin address without matching.

 

Name: Freicoin Alliance Website: http://freicoinalliance.com Email: [email protected] Freicoin address: 1EcMiqBNfVi5SfSaCu8GAEwcnz1ArXyoaC Bitcoin address: 1MWR3nWHrqJyVnGUnAM6xtXxidtSvjcji8 Short description: Help the Freicoin Community to create a world full of charitable action and sustainable development - Help to to propagate Freicoin! Long Description: Freicoin Alliance is a Freicoin community driven project that seeks to create a world with the Freicoin fundamentals, a social structure, in which all of humanity is free and equal. We aim to drive and inspire people to contribute their talents, ideas and passion to projects benefiting the common good of their communities and the world as a whole. We hope to establish communities to share opinions, research and projects to achieve scientific and technological progress, to allow personal growth and establish local guidelines based on the needs of the people in a local and global context. We hope to see societies develop where culture, arts and knowledge of nature can flourish that allows all people to experience life to the fullest.