Jump to content

Arcurus

Moderators
  • Content Count

    747
  • Joined

  • Last visited

  • Days Won

    66

Posts posted by Arcurus

  1. Hi all,

    here is a draft, how the current blocksize could be increased though using a soft fork similar to segwit. Please outline my errors if you find some.

    All the good,

    Arcurus

     

    Introducing extended blocks:

    - like with segwit an extended block is used to have extra space

    - these extended block is referenced from the normal block

    - transactions can be either stored in normal block or the extended block

    - the old block plus the extended block is not allowed to be bigger then the new extended block size

    - so called extended transactions that can be stored in the extended block, must mark their output to be spent by all according to the logic of the old nodes

    - enforced through a soft fork only transactions are allowed to be placed in the normal block that are not conflicting transactions in the extended block

    - once activated updated nodes will not propagate conflicting blocks and transactions

     

    With this in place old nodes would only process transactions up to the 1 MB block limit. Updated nodes could use the extended block on top of that to process extended transactions. If the fee is high enough, extended transactions can also be included in the normal block.

     

    Implementation:

    - the output of transactions once included in the extended block could only be spent again though using the extended block. With time this will naturally dry out the normal block (if not manifested, see below)

    - since transactions in the extended block can be spent by all according to the old nodes, a so called manifestation transaction could be used if needed to manifest what was happening in the extended block

    - to be valid according to the old nodes these manifestation transactions would naturally need to include at least the initial transactions, which marks the output to be spent by all according to the old block logic

     

    Introducing a Multi tier block chain:

    The same way as outlined in Extended Blocks we could use a multi tier block chain architecture.

     

    More to that you can find here:

     

  2. Here a draft that includes also a dividend (basic income) to all members (I like the distribution, because it has the golden distribution rule 1 / 5):

     

    POW + POS + POM (proof of member) example:

    Transaction fees plus demurrage coins plus not yet distributed coins are distributed the following way:

    20% goes to proof of work block creators at max (this number is not set in stone and could be reduced if the blockchain is successfully secured with other methods).

    20% goes to stake voters

    20% goes to member voters

    20% is assigned to projects according to the stake votes

    20% is assigned to projects according to the member votes

     

    Introducing proof of member:

    - in each block 8 member groups  from a so called ¨members group list¨ are chosen through using the proof of work hash

     

    Introducing Member Transactions:

    - member transactions are handled similar to stake transactions (see above post)

    - each stake or member transaction must link to one block and can only be included in the next block after the linked block

    - for each included stake or member transaction the difficulty target of this block is reduced by 5% 

    Example: If a block includes all possible 16 stake / member transactions the difficulty of this block is reduced by 16 * 5% = 80% 

    - each stake or member transaction gets  2.5% of the coins to distribute in this block (in total max 20% for all stake transactions and 20% for all member transactions)

    - each stake or member transaction can assign up to 2.5% of the coins to distribute to a project address (therefore in total max 40% of the issued coins) 
     

    Introducing Member groups:

    - member groups have a member count that indicates how many members this group has

    - a single member is simply a member group with the count 1

    Example: a member group with a member count of 10 has 10 times the chance to be chosen for creating an member transaction then a single member has

     

    Introducing Member Group List:

    each stake or member transaction can vote for a member groups 

    each stake or member transaction can vote against a member group

    - an member group becomes added to the member list if it has at least 16 positive votes and at least 2/3 positive votes 

    - an member group becomes removed from the member list if it has at least 2/3 negative votes 

    - optional: after one year a member group must be again approved or the member count is halved (rounded down)

    - optional: for each added member the average payout* per member for one month must be paid as fee

    Example: average payout for one month = 20% of the demurrage of this month / member count

  3. Finally here now the first draft for decentralizing the coin issuing / freicoin foundation:

    This draft has mainly two parts. The first part is how to improve the network security and on the same time reduce the problem that miners could block votes for the coin issuing through using an Proof of Work (POW) Proof of Stake (POS) combination. The second part is about how on this fundament a decentralized coin issuing could look like.

    As alway feel free to comment! 

     

    POW + POS example:

    20% of the transaction fee plus demurrage goes to proof of work block creators at max (this number is not be set in stone and could be reduced if the blockchain is successfully secured with other methods).

    20% goes to proof of stake voters

    60% is assigned to projects according to the proof of stake votes

     

    Introducing coin voting:

    - in each block 8 stakeholders are chosen, the more stake the more likely they are chosen through using the proof of work hash

    - all non distributed foundation coins and all non distributed demurraged coins are called not yet distributed coins

    - not yet distributed coins are not considered as distributed and therefore do not take part in voting

    - optional: addresses with less than 1 coin are not considered in the voting (to remove dust in the unspent set that is relevant for consensus)

    - optional: not moved coins for one month are not considered in the voting if they didn't sign at least one stake transaction in the last month  

     

    Introducing Stake Transaction:

    - each chosen stakeholder can create a so called ¨stake¨ transaction

    - each stake transaction must link to one block and can only be included in the next block after this linked block

    - for each included stake transaction the difficulty target of this block is reduced by 5% (10% if not using prof of member, see other post below)

    - coins to distribute in this block are the transaction fees plus the demurraged coins plus the not yet distributed coins

    - coins to distribute are maximal 5 times the demurraged coins plus the transaction fees

    - each stake transaction gets  2.5% of the coins to distribute in this block (therefore in total max 20% for all stake transactions) 

    - the POW block creator gets allways 20% of the fees + 20% of the coins to distribute in this block 

    - all not claimed coins to distribute are added to the not yet distributed coins

     

    Decentralized POS based coin issuing:

    - each stake transaction can assign up to 2.5% (7.5% if not using prof of member) of the coins to distribute to a project address (therefore in total max 20% for all stake transactions / 60% if not using proof of member) 

    - these coins are called project coins

     

    Voting for White Listed addresses:

    - payouts to projects are done after one day

    - each stake transaction can vote negative for one project address

    - the payout amount of a negative voted project address is reduced by the payout amount of the stake transaction that is voting negative for this project address

    - optional: each stake transaction can additionally also vote to undo a negative vote. Undo votes can be given also in advance.

    Example: With undo votes it will need 2/3 of the voters to suppress 1/3 of the voters

  4. On 1/9/2017 at 1:02 PM, Rik8119 said:

    And to me Grantcoin is a nice project but it is just fiat money with a basic income. And as far as the theory for freicoin is considered it will lead to ever rising prices, that will again give advantages to big cooperations.

    why is grantcoin fiat money? Yes grantcoin will lead to rising prices, but not necessarily this gives advantages to big corporations. As long as the newly created money is given directly to the people, the people have the most benefit and cannot be dried out like in the current interest / debt based system or in an gold like system which will ultimately again lead to a interest / debt based system, because it accumulates with time.

  5. Mainly we need to improve the following:

    - Secure the blockchain

    - bring the coin issuing / foundation to run or replace it

    once the coin issuing is functioning, we could give incentives for using freicoin

    How could Freicoin 2.0 lesson learned look like:

    - use merge mining or alternative mining alg that only freicoin has

    - switch to a combination of proof of work and proof of stake

    POW + POS example:

    - in each block 8 stakeholders are chosen, the more stake the more likely they are chosen

    - foundation coins are not considered as stakeholders

    - addresses with less than 1 coin are not considered as stakeholders (to remove dust in the unspent spet that is relevant for consens)

    - not moved coins for one month are not considered as stakeholders if they didn't sign at least one stake transaction in the last month  

    - each chosen stakeholder can create a so called ¨stake¨ transaction

    - each stake transaction must refer one block and can only be included in the next block after this refered block

    - the block which includes a stake transaction needs -10% difficulty for each included stake transaction

    - each included proof of stake transaction gets 10% of the fees + 10% of the coinbase coins

     

    If we would have this in place, how could the coin issuing look like?

    - each stake transaction can assign up to 10% of the demurraged coins to so called ¨white listed addresses¨ 

    - as long as there are non distributed foundation coins, each stake transaction can assign additional up to 10 times the value of the demurraged coins from the unspent foundation coins to the to so called ¨white listed addresses¨

    with this in place and a demurrage of 5% per year, foundation coins could be at best issued in 2 years

    - white listed addresses are enforced by a softfork through miners / stakeholders / nodes

    for example the same like voting for bitcoin softforks: new addresses need 2/3 approval and are valid for one year or at max X coins. Addresses can be removed by setting x to 0  

     

     

  6. On 11.9.2016 at 1:14 PM, Bicknellski said:

    Freicoin? 

    lol yea, I read the loan agreement up to point 2 :)

     

    As said im fine with Bitcoin repayment.

    In future I would suggest to support loans done in Freicoin with Alliance funds, so that we have incentives to use Freicoin.

     

    On 11.9.2016 at 1:14 PM, Bicknellski said:

    Got it holding in reserve I hope the Rupiah doesn't crash.

     

    lol, i hope the dollar doent crash as it is expected for the next months....

     

    Seems already to start:

    https://bitcoinity.org/markets

  7. Hello,

    I tried to start FreicoinQt 64 bit on Unbuntu Mint, but the following error comes:


    ./Freicoin-Qt: symbol lookup error: ./Freicoin-Qt: undefined symbol: SSLv2_client_method

    Seems like SSLv_2 is not supported, because it has known security issues:

    ¨The Ubuntu people build OpenSSL without SSLv2 support because the protocol has known security issues. So that's why you can't find SSLv2_method in their library even though you can find it when you compile the library yourself.¨

    https://stackoverflow.com/questions/8206546/ubuntu-and-undefined-symbol-for-sslv2-method
     

    Is there a workaround / or even better, can it be fixed?

  8. To accounting currency:

    Yes I can understand that you have exchange risk, especially with using Freicoins. To cover that I suggested to grant some extra Freicoins, so that there is an incentive to use Freicoins. And yes, for this loan it does not matter so much which currency we choose, its more generally a question how we want to handle loans. Therefore I suggested to use a fair stable Value like Freihours / or you can also call it inflation free dollars (the interest would be the inflation during the loan period). Generally I would also combine it with some kind of basic income / universal dividend so even if the price drops dramatically of Rupia you could use the universal dividend to pay back.

     

    To the loan contract:

    I think its not clear to which Freicoin exchange rate you will pay back. And if you prefer to payback in Freicoins, I would like to prefer to use another Freicoin related payback address.

  9. I would suggest to support common good loans like this with Alliance funds.

    My suggestion would be 10% for the borrower and 10% for the lender if the loan transactions are made in Freicoin or Freihours.

    The lender get the Freicoins after giving the loan, the borrower after payback.

     

    Granted Freicoin amount per user / user group may be limited.

    I will borrow the needed Freicoins and donate my granted coins to Bicks School project.

     

    What do you think?

     

  10. Hi Bick,

    I have sent you 0,01 BTC to this address as test: e44494760346d922b897fa416e5d6e6709916fb430a941ef9f6a12d1e014ef13

    As Rik I also would prefer to have it as simple as possible at the moment.

    You can sent back the coins to the sending address.

    To the loan itself.

    I thought the loan is in dollars / Freihours not in Rupia?

    Generally I would prefer to have loans counted in the stable unit Freihours, who knows if dollars or Rupia collapses...

     

    To make it easy i would suggest to equal one Freihour to the purchasing value of one average working hour, currently 10 dollars, at the moment of the loan. If the purchasing power of dollar goes down for example 10% until the loan is payed back then 11 dollars must be payed back...

    In away the loan would be counted in dollars and the interest would equal the inflation rate.

    I think that would be fair for both parties and nominated in purchasing power this would still be a 0 interest loan.

    Its not so much about this loan its just generally question.

    What do you think? 

  11. On 30.8.2016 at 7:21 AM, Bicknellski said:

    BTC so we don't have issues with exchange like last time be best. I like the idea of Freihours to Rupiah as well as long as we don't have any significant exchange losses either way to either party.

    Hi Bick,

    wasn't it the last time the same? We set the price in dollars.

    I for my part will loan interest free 9.5 Freihours = 95 dollars (same amount counted in Freihours / dollars is expected to be paid back)

    With not having a stable Freicoin price currently I prefer to give it in Bitcoin to the exchange rate of the day of the transaction.

    The same way back. As send back address you can take the same address where the funds came from.

    Once you have the address ready i will sent you the coins as soon as possible.

  12. 23 hours ago, Rik8119 said:

    Interesting how the activity in this forum is linked to the volatility of the bitcoin price.. ;-).

    lol yea, we should better like it to the ethereum price :)

    I guess soon bitcoin price will also be more volatile, down if etherum suceeds, up if not.

    I hope that i contact marc how he wants to proceed with freicoin.

    Without having the core devs fixing at least the basics its very very hard.

×
×
  • Create New...