FreiCoin (FRC) Fork WITHOUT 80% Of Coins Given To FreiCoin Foundation

[Impaler]

jancsika:  You should put these idea on our forums ware we are discussing the structure and bylaws of the foundation.  http://www.freicoin.org/freicoin-foundation-f15.html is our new sub-forum for such discussions.

[1715313546]

1715313546

[1715313546]

1715313546

[1715313546]

1715313546

[🏰 TradeFortress 🏰]

After thing about this issue a bit, the problem is the foundation ALREADY has 8 million Freicoins. We need to create a new coin, but I suggest something different.

Currently, all cryptocurrencies are based off Satoshi's bitcoin, with same or slightly modified protocols, and only some modifications (eg demurrage in Freicoin, block timings and distributions with other coins, proof of stake with PPCoin). But look at all the failed cryptocurrencies - we are essentially making a new Linux distro instead of actually making something new.

I propose making a new cryptocurrency from scratch and discussing and testing different ways to do it. Blockchain, hashcash-style mining, addresses, they're all one way to do things. There's bound to be better ways, and for a cryptocurrency to succeed we need to do it differently. Not blindly do things differently, but look at it and see which way is BETTER other than just creating a fork and modifying a bit of code from bitcoind.

I have a few ideas. For example, addresses. Instead of a clunky to remember, hard to type address, why not use something like this?

someguyswebsite.com/wallet
dicegame.com/lessthan512
192.168.0.12/lanpartydonations
wc6sbavw7fcotfgm.onion/order1274621
mywallet.bit/someusername

To verify those addresses, we could use a similar system to randomart. There's of course the attack where say you're on dicegame.com is compromised and the attacker changes the randomart displayed on the site for verification, but that's similar for bitcoin too. The coin obviously won't actually use http, it'll use it's own protocol, but will find addresses via DNS, tor, other darknets, etc etc.

Again, this is just one of the ideas I have about addresses. I'm sure if people think about it, experiment with some test code, we'd come across different ways, maybe better.

Another important thing is that the core development needs to be just that - core. Make the protocol extensible. Have headers, like HTTP requests. Over time, the community will enhance this currency by itself. For example, say a header called 'RETURN_ADDRESS: freewallet.org/ponies', say if you're betting on a gambling game and send an amount greater than the max bet, and you want returns in a DIFFERENT address (eg if you're withdrawing from an exchange) It's a nice thing to have, but it might not need to be in the core development. People will be able to add this feature, peers and nodes would implement and support it.

Take a look at websockets. Take a look at new IRC features and additions. If we make the protocol robust and extensible, the currency will involve by itself, and with the community and the users to make it last. There obviously would be a core set of guidelines - max cap of X coins, but if we discover a BETTER address system, maybe if someone wants to make it work with emails, they can code a module or extension, tell people and nodes to install and use it, and supported clients will use it automatically. Not supported? "Command not found. This command is part of coinemail, sudo cpm install coinemail".

Just some ideas. Can we do a system where transactions have a verifiable sending time? Use the hashcash mining system. A new "timecode" every 20 seconds (as it is not a block, it is not coupled with transactions, each timecode would just be a few bytes). Transactions would include the latest timecode as proof of when it was sent. First sent coins triumph in double spend attacks. Still vulnerable to 51% attacks, but again this is just one idea.

[galambo]

After thing about this issue a bit, the problem is the foundation ALREADY has 8 million Freicoins. We need to create a new coin, but I suggest something different.

Currently, all cryptocurrencies are based off Satoshi's bitcoin, with same or slightly modified protocols, and only some modifications (eg demurrage in Freicoin, block timings and distributions with other coins, proof of stake with PPCoin). But look at all the failed cryptocurrencies - we are essentially making a new Linux distro instead of actually making something new.

I propose making a new cryptocurrency from scratch and discussing and testing different ways to do it. Blockchain, hashcash-style mining, addresses, they're all one way to do things. There's bound to be better ways, and for a cryptocurrency to succeed we need to do it differently. Not blindly do things differently, but look at it and see which way is BETTER other than just creating a fork and modifying a bit of code from bitcoind.

I have a few ideas. For example, addresses. Instead of a clunky to remember, hard to type address, why not use something like this?

someguyswebsite.com/wallet
dicegame.com/lessthan512
192.168.0.12/lanpartydonations
wc6sbavw7fcotfgm.onion/order1274621
mywallet.bit/someusername

To verify those addresses, we could use a similar system to randomart. There's of course the attack where say you're on dicegame.com is compromised and the attacker changes the randomart displayed on the site for verification, but that's similar for bitcoin too. The coin obviously won't actually use http, it'll use it's own protocol, but will find addresses via DNS, tor, other darknets, etc etc.

Again, this is just one of the ideas I have about addresses. I'm sure if people think about it, experiment with some test code, we'd come across different ways, maybe better.

Another important thing is that the core development needs to be just that - core. Make the protocol extensible. Have headers, like HTTP requests. Over time, the community will enhance this currency by itself. For example, say a header called 'RETURN_ADDRESS: freewallet.org/ponies', say if you're betting on a gambling game and send an amount greater than the max bet, and you want returns in a DIFFERENT address (eg if you're withdrawing from an exchange) It's a nice thing to have, but it might not need to be in the core development. People will be able to add this feature, peers and nodes would implement and support it.

Take a look at websockets. Take a look at new IRC features and additions. If we make the protocol robust and extensible, the currency will involve by itself, and with the community and the users to make it last. There obviously would be a core set of guidelines - max cap of X coins, but if we discover a BETTER address system, maybe if someone wants to make it work with emails, they can code a module or extension, tell people and nodes to install and use it, and supported clients will use it automatically. Not supported? "Command not found. This command is part of coinemail, sudo cpm install coinemail".

Just some ideas. Can we do a system where transactions have a verifiable sending time? Use the hashcash mining system. A new "timecode" every 20 seconds (as it is not a block, it is not coupled with transactions, each timecode would just be a few bytes). Transactions would include the latest timecode as proof of when it was sent. First sent coins triumph in double spend attacks. 3 confirms in 1 minute on average. Still vulnerable to 51% attacks, but again this is just one idea.

Please stop.

[🏰 TradeFortress 🏰]

After thing about this issue a bit, the problem is the foundation ALREADY has 8 million Freicoins. We need to create a new coin, but I suggest something different.

Currently, all cryptocurrencies are based off Satoshi's bitcoin, with same or slightly modified protocols, and only some modifications (eg demurrage in Freicoin, block timings and distributions with other coins, proof of stake with PPCoin). But look at all the failed cryptocurrencies - we are essentially making a new Linux distro instead of actually making something new.

I propose making a new cryptocurrency from scratch and discussing and testing different ways to do it. Blockchain, hashcash-style mining, addresses, they're all one way to do things. There's bound to be better ways, and for a cryptocurrency to succeed we need to do it differently. Not blindly do things differently, but look at it and see which way is BETTER other than just creating a fork and modifying a bit of code from bitcoind.

I have a few ideas. For example, addresses. Instead of a clunky to remember, hard to type address, why not use something like this?

someguyswebsite.com/wallet
dicegame.com/lessthan512
192.168.0.12/lanpartydonations
wc6sbavw7fcotfgm.onion/order1274621
mywallet.bit/someusername

To verify those addresses, we could use a similar system to randomart. There's of course the attack where say you're on dicegame.com is compromised and the attacker changes the randomart displayed on the site for verification, but that's similar for bitcoin too. The coin obviously won't actually use http, it'll use it's own protocol, but will find addresses via DNS, tor, other darknets, etc etc.

Again, this is just one of the ideas I have about addresses. I'm sure if people think about it, experiment with some test code, we'd come across different ways, maybe better.

Another important thing is that the core development needs to be just that - core. Make the protocol extensible. Have headers, like HTTP requests. Over time, the community will enhance this currency by itself. For example, say a header called 'RETURN_ADDRESS: freewallet.org/ponies', say if you're betting on a gambling game and send an amount greater than the max bet, and you want returns in a DIFFERENT address (eg if you're withdrawing from an exchange) It's a nice thing to have, but it might not need to be in the core development. People will be able to add this feature, peers and nodes would implement and support it.

Take a look at websockets. Take a look at new IRC features and additions. If we make the protocol robust and extensible, the currency will involve by itself, and with the community and the users to make it last. There obviously would be a core set of guidelines - max cap of X coins, but if we discover a BETTER address system, maybe if someone wants to make it work with emails, they can code a module or extension, tell people and nodes to install and use it, and supported clients will use it automatically. Not supported? "Command not found. This command is part of coinemail, sudo cpm install coinemail".

Just some ideas. Can we do a system where transactions have a verifiable sending time? Use the hashcash mining system. A new "timecode" every 20 seconds (as it is not a block, it is not coupled with transactions, each timecode would just be a few bytes). Transactions would include the latest timecode as proof of when it was sent. First sent coins triumph in double spend attacks. 3 confirms in 1 minute on average. Still vulnerable to 51% attacks, but again this is just one idea.

Please stop.

Thank you for your informative and compelling comment, galambo.

[ArticMine]

So I take this fork / 51% takeover of FreiCoin is now dead.

[jjiimm_64]

After thing about this issue a bit, the problem is the foundation ALREADY has 8 million Freicoins. We need to create a new coin, but I suggest something different.

Currently, all cryptocurrencies are based off Satoshi's bitcoin, with same or slightly modified protocols, and only some modifications (eg demurrage in Freicoin, block timings and distributions with other coins, proof of stake with PPCoin). But look at all the failed cryptocurrencies - we are essentially making a new Linux distro instead of actually making something new.

I propose making a new cryptocurrency from scratch and discussing and testing different ways to do it. Blockchain, hashcash-style mining, addresses, they're all one way to do things. There's bound to be better ways, and for a cryptocurrency to succeed we need to do it differently. Not blindly do things differently, but look at it and see which way is BETTER other than just creating a fork and modifying a bit of code from bitcoind.

I have a few ideas. For example, addresses. Instead of a clunky to remember, hard to type address, why not use something like this?

someguyswebsite.com/wallet
dicegame.com/lessthan512
192.168.0.12/lanpartydonations
wc6sbavw7fcotfgm.onion/order1274621
mywallet.bit/someusername

To verify those addresses, we could use a similar system to randomart. There's of course the attack where say you're on dicegame.com is compromised and the attacker changes the randomart displayed on the site for verification, but that's similar for bitcoin too. The coin obviously won't actually use http, it'll use it's own protocol, but will find addresses via DNS, tor, other darknets, etc etc.

Again, this is just one of the ideas I have about addresses. I'm sure if people think about it, experiment with some test code, we'd come across different ways, maybe better.

Another important thing is that the core development needs to be just that - core. Make the protocol extensible. Have headers, like HTTP requests. Over time, the community will enhance this currency by itself. For example, say a header called 'RETURN_ADDRESS: freewallet.org/ponies', say if you're betting on a gambling game and send an amount greater than the max bet, and you want returns in a DIFFERENT address (eg if you're withdrawing from an exchange) It's a nice thing to have, but it might not need to be in the core development. People will be able to add this feature, peers and nodes would implement and support it.

Take a look at websockets. Take a look at new IRC features and additions. If we make the protocol robust and extensible, the currency will involve by itself, and with the community and the users to make it last. There obviously would be a core set of guidelines - max cap of X coins, but if we discover a BETTER address system, maybe if someone wants to make it work with emails, they can code a module or extension, tell people and nodes to install and use it, and supported clients will use it automatically. Not supported? "Command not found. This command is part of coinemail, sudo cpm install coinemail".

Just some ideas. Can we do a system where transactions have a verifiable sending time? Use the hashcash mining system. A new "timecode" every 20 seconds (as it is not a block, it is not coupled with transactions, each timecode would just be a few bytes). Transactions would include the latest timecode as proof of when it was sent. First sent coins triumph in double spend attacks. Still vulnerable to 51% attacks, but again this is just one idea.

sounds like it will be too difficult to prevent hacking with all those 'features' built in..  

The reason bitcoin is popular is because of its 'simplicity' and security.  You could probably build what your talking about on top of bitcoin, similar to blockchain.info but with all the new address features and such.  but still have the bitcoin underneath providing the verification and security..  

KISS

[ElectricMucus]

So I take this fork / 51% takeover of FreiCoin is now dead.

There is still not enough hasing power overall to state any such conclusion. Any beefy BTC miner could probably do it himself for the lulz.

[galambo]

So I take this fork / 51% takeover of FreiCoin is now dead.

Unfortunately, it never got off the ground. We're completely open to people that want to use our work to accomplish their own goals, as long as they do it competently. It was impossible for it to work how it was coded. I really hope TradeFortress is done posting about this. It's very embarrassing for him. I'm not sure if hes completely unaware of that or this is some weird troll.

[nethead]

So I take this fork / 51% takeover of FreiCoin is now dead.

Unfortunately, it never got off the ground. It was impossible for it to work how it was coded. I really hope TradeFortress is done posting about this. It's very embarrassing for him. I'm not sure if hes completely unaware of that or this is some weird troll.

yup i agree never got off the ground, we still wait for the bins

[🏰 TradeFortress 🏰]

So I take this fork / 51% takeover of FreiCoin is now dead.

Unfortunately, it never got off the ground. It was impossible for it to work how it was coded. I really hope TradeFortress is done posting about this. It's very embarrassing for him. I'm not sure if hes completely unaware of that or this is some weird troll.

yup i agree never got off the ground, we still wait for the bins

I'm really not going to focus any time on this fork because I think the best approach would be a new cryptocurrency protocol. Feel free to submit pull requests through.

[hanzac]

I'm really not going to focus any time on this fork because I think the best approach would be a new cryptocurrency protocol. Feel free to submit pull requests through.

I don't think there's need to implement a new currency, unless you find a better encryption method than SHA-256 or scrypt or you find/think the current currency is not fair, price is manipulated by some early investors and hard to thrive.

I think the current BTC mode is acceptable, you can create new application to extend the use. I also like the idea to re-implement the protocol in other language than C++.

[Bicknellski]

So I take this fork / 51% takeover of FreiCoin is now dead.

Well, I don't get it. TF apparently doesn't want it to take off.
What was his change to the code anyway? Why is it a problem that the foundation already has the coins? If moving these coins never makes it into a block there is no problem.

Read the thread... the answers are all there. If you want your own coin that has none of these features... create it. Right? Since the topic is dead might as well lock it and have you start a new topic about your super duper new coin without the 80% trust.

[jtimon]

I have a few ideas. For example, addresses. Instead of a clunky to remember, hard to type address, why not use something like this?

someguyswebsite.com/wallet
...

Those clunky to remember addresses are the hash of a public key. The public key is part of a key pair composed of public and private key.

http://en.wikipedia.org/wiki/Public_key

Good luck with your fork, it seems you will need it.

[stiff]

May I ask you a two questions about FreiCoin?
- How long blocks is immature  or  need confirmation?
- Award for the block is constant?
Thanks.

[galambo]

May I ask you a two questions about FreiCoin?
- How long blocks is immature  or  need confirmation?
- Award for the block is constant?
Thanks.

1) 120 blocks need to be mined until maturity
2) The reward is not constant, but it is predictable. It starts out at ~250 per block, and linearly decreases to a steady state value of around 100 coins per block @ around 160000 blocks mined. Each block mined will always have a reward at least 100 until the end of time. For the actual eqn you can find it in the client sourcecode.

[ASICSRUS]

Freicoin foundation?

wots dat? /\

[maaku]

We're working on it:

http://foundation.herokuapp.com/

[ASICSRUS]

We're working on it:

http://foundation.herokuapp.com/

 
is this you~> https://github.com/jtimon

[maaku]

That's my colleague, who goes by jtimon on these forums. This is me:

https://github.com/maaku/

[ASICSRUS]

why is FrieCoin so undervalued on the exchange?...i'm grabbing more down here!!!~keep it up/\