All Activity
This stream auto-updates
- Today
-
To make a rough calculation for the mined coin supply it will look something like this: mid next year: 162 000 coins in 2 year: 130 000 coins 3: 106 000 coins 4: 88 000 coins 5 81 000 coins a.s.o. So quite some gross deflation in total.
- Yesterday
-
Additionally i will add the possibility do give the internal bot transactions a message so merchants can link those transactions to a specific sale.
-
The Solidarbot is planned also to be active on Telegram and Whatsapp. It is planned that you create a user account with the facebook bot and then use the bot to link your Telegram id to the bot in Telegram, so he knows you are using this app also. In that way you do not need to install the messenger on your phone if some other is already installed.
-
Ok, i found someone from italy that already organized some meetings for freimoney projects in italy and agreed to take care of the homepage. If you have any suggestions feel free to bring them in.
- Last week
-
well anyway, it works better if you start with no block chain downloaded (empty chaindata\) then run C:\Users\Reza\AppData\Roaming\Ethereum Wallet\binaries\Geth\unpacked\geth --syncmode "fast" --cache 1024 console. That loads chain much faster. After that, run wallet. I'm not sure how wallet performance will be after that. more info: https://theethereum.wiki/w/index.php/Ethereum_Wallet_Syncing_Problems#How_to_recover_from_slow_syncing.3F
-
.
-
i was thinking of something like this (sort of with a kria).. Kria to the moon!
-
But the time is over. And their first declaration was already recorded. i could be completely wrong here. But I value the 'back to basics' thought process to see what exactly is meant or required to happen. After a few ego 'releases' it is actually fun. it seems to me the POW essentially does 3 things: (1) choose a unique person to issue the block; (2) maintaing the 10 min pace (allowing time for transactions to be transmitted accross the network and for people to assemble blocks); (3) third 'to have skin in the game' to not cheat. The second can be achieved by a clock, the first through a lottery, and the third with a deposit. I am purposely not going back to do research here to make sure I am not just being a parrot but creating a reasoning. but I could be wrong, that's the thought excercise. Tonight I will go back to Satoshi's white paper. Oh. The fourth is to ward off DOS attacks. Added later: I think part of the answer to my question is that my scenario uses essentially a usenet. Where as Satoshi says POW is needed to establish a time stamp server on a peer to peer network.
-
After the random value is released, I go back and make up a proposed block that's even closer.
-
Back to basics. Please endulge me: Why can't something like this work instead of POW? 1) Master clock starts at 0 2) At a special viewing area, a number is randomely chosen and put in a closed "box" and put in central viewing area (but number remains nonvisible). 3) for 10 minutes, nodes compile block. When they are ready to submit, they announce they have a block and submit it with another randomly produced number. 4)At the end of the 10 minutes, the random number is revealed, and the node that submitted closest number wins. A variation is, a node is selected at random to be the 'viewing area' and selects the first random number. This node cannot contribute a block. Oh! And nodes submitting a block submit a fee that will be reimbursed unless their block is bad, then it goes to the winner.
-
Gobsmacked. You really buried the lead for the most interesting possible updates. This is most interesting aspect of what you are planning for FRC. If you can help crack that and get FRC in that arena and at the forefront maybe there is hope for wider adoption. Personally when I first came to bitcoin it was a huge liability I saw where those with technical skills, resources, lower power costs would eventually 'control the coin'. Centralized mining in the hands of only a few corporations or organizations and a lot fraud has happened as a direct result of this race to centralization. Everyone has a phone. Everyone. I always hoped to see something where POW mining was on every hand-phone on the planet and it was not a massive warehouse requiring coal fired plants being fired up in Inner Mongolia securing the network. I will be following that thread closely and I hope there is a potential to bring mining back to the small scale really individuals rather than a collective entity with massive resources. I will read up on the link you posted.
-
All back to normal with multiple markets. The next few weeks we will adjust a few things (design, speed, added markets) Thanks. (you can reach us on telegram almost 24/7 )
- Earlier
-
Of course there is a solution to that, its called: closed source! Just add some stinky unnecessary features that makes it impossible to read the blockchain without your client and you got it... But that was the world before Bitcoin, so i guess no one (well, excepting Roger and Jihan) wants to go back there.. Its not a bug, its THE feature! And yes, you can still run the software from 2009 and refuse to update. But again who wants that? In the end its a consensus that is reached by following the chain with enough marketcap to make it work..
-
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).
-
Is there something that can be done so that the blockchain cannot be copied with a hardfork like BCC? It seems to me now, BCC has proven that Bitcoin is not a trustless system. Am I wrong in my perception of this? But I realize I am asking to make a hardfork that won't allow hardfork ...
-
Perfect. I will use that excuse for the explorer too.
-
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.
-
How can that happen? How does the wallet allow you to send more then you have? Demurrage is deducted every block, when you open your wallet. But there is a difference of 1 satoshi. So it's really close.
-
I would like to help with the testing.
-
This transaction is invalid: 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: This is already in bitcoin, and will be in freicoin as soon as we upgrade the reference client to a more recent upstream version. Likewise! Freicoin will get the same segwit that bitcoin is about to lock-in. Still want this for Freicoin, but: 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. 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.
-
Okay glad to get some important background on why the foundation needs to go bye bye. Thanks for sharing the road forward I am looking forward to the changes and further discussions as to pegging and moving old chain to new chain idea. I think a grand display of the destruction and the plan moving forward should be posted. Do a live stream ending the foundation coins perhaps?
-
@Mark Friedenbach Yup. I meant 'currency split' as in 'stock split'.
-
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.
