Jump to content

Arcurus

Moderators
  • Content Count

    747
  • Joined

  • Last visited

  • Days Won

    66

Posts posted by Arcurus

  1. Hi Rik,

    yes we don't need donation matching, we could distribute the coins directly to people. The donation matching was just a workaround with the current issuing. I don't think airdrops are a good solution, they don't solve any problem in a sustainable way.  

    I would prefer to give people a steady amount of coins per time period. This would encourage long term use of the coin and long term fair money distribution. 

     

  2. 6 minutes ago, Skaro said:

    I can do some testing. My computer skills are not so great as to be able to build a wallet without a dummy's guide, but Im willling to learn and put in the time.

    great to have you!

    Best is to coordinate directly with fedde, he has the overview and the direct contact also to maaku.

  3. Hi Sarko,

    to 1) lol yea the thermodynamics :)... it's both the thermodynamics / work securing the chain, and the right to include a transaction

    to 2) attempt yes, success most likely not long.... by the way, also here dahs pow algorithm sound more promising than script mining.

    to 3) confirmations currently is pow, therefore see 1) thermodynamics :).

    The balance is known? yes and no. No because it is not known to 100% if the balance stays like it is, because currently longer pow chain can undo the balance. And not necessarily 100% of the nodes agree on the same balance. And yes, because nodes could enforce an certain chain, like forexample steem or dash does it with their masternodes, or you can use the ripple / stellar protocol to come to a consens.

    to 4) poof of stake and proof of work favor ¨rich¨ people. Therefore i want to go towards proof of member which is described here: (Currently im also working on an fair coin distribution on top of the masternode concept)

     

     

  4. its really sad currently in Bitcoin, it seems that the main mining hardware provider doesnt like core and now tries to make a bitcoin fork with bitcoin unlimited.

    Its really sad, that they block segwit, which would increase the blocksize 2 fold.

    It's also really sad, that the core developer still don't have coded or even described an way beyond the current 1 mb limit as promised to the miners.

    I more and more see no good reason for proof of work other than a coin distribution and the simplicity of it. But the problem is with time one single company will more and more dominate the mining and therefore destroy decentralisation. Only solution to that would be to switch the mining alg quite often or don't use mining at all.

    Also mining facilities are more and more centralized and easy to attack.

    I more and more look into other ways of securing the block chain:

    Mainly i see these three different solutions out there, each of them could be implemented in an second tier:

     

    Using Masternodes like dash:

    https://dashpay.atlassian.net/wiki/display/DOC/Whitepaper

    Using Forking / pure proof of stake (in the second layer) like nxt:

    https://www.dropbox.com/s/cbuwrorf672c0yy/NxtWhitepaper_v122_rev4.pdf

    Using delegated proof of stake like steem and bitshares:

    https://bitshares.org/technology/delegated-proof-of-stake-consensus/

     

    all three also have allready voting and budget systems.

    Dash and steem have nearly instant transaction confirmation

    nxt steem / bitshares allow allready decentralised exchanges

    steem would provide even the possibility to use as decentralised forum.

     

    Dos anybody know something about successful attacks against one of them? (I mean attacks like double spending)

    NXT:

    Simplified as far as I understood, next chooses one stakeholder that can then create the next block. the more coins you have the more likely he is chosen. 

    If this stakeholder does not create a block, the next in line can create one.

    Both problems could be solved or hardly reduced through using some kind of proof of work combination to elect the next forker. The proof of work could also be used to making it hard for an forker to sign two competing blockchains. 

     

    Problems with NXT based forking:

    As far as i know is that next had some problems, because their forking / block creation allows at no cost creating different blocks, but i have to research it.

    Also I don't know yet how exactly the next stakeholder is chosen. It seem to me, that someone who created a block can try to choose again one account under his control.

     

    Dash:

    Dash uses the proof of work to elect 10 masternodes form the masternode list. A masternode node needs to have 1000 dash which is currently more then 40000 dollar.

    These 10 elected master nodes then lock transactions. Blocks that double spent these locked transactions are simply ignored.

    Problems with Masternodes:

    Up to know i didnt hear about an successful attack, but i didnt research yet.

    To me it lookes like if 1 elected masternode could block the locking of transactions. Therefore 10% to 20% masternodes could block most of the locking consens.

    This would be easily solvable by requiring only 2/3 of the chosen masternodes to agree. 

    Also i dont know yet how they exactly solve race conditions if one set of masternodes locked one transaction, and a set chosen in another created block locks the double spent transaction.

    This race conditions could be reduced by using an older bock, lets say one hour ago to elect the next masternodes.

    Another attack vector would be when the shift between the old elected masternode set and the new happens.

    The old masternodes could lock one transaction while the new masternodes lock the double spent transaction.

    This could be solved by electing / replacing only one of 10 masternodes in each block. 

    In this case the new set of elected masternodes will know what the old sett locked and therefore dismiss double spent attacks.

     

    bitshares / steem:

    In short, each stakeholder can vote for up to X (30) block creators (they can even delegate their vote)

    The top 21 are the new set of block creators. In each round each block creator can exactly create one block at an scheduled order.

    Problems with delegated proof of stake:

    Up to know i dont know about any attack vector other then 50% +1 of the elected block creators colluding, which would be similar to 50%+1 of the miners in bitcoin colluding.

    For me it lookes at least more easy to attack then the masternode network, but still an attack doesnt look that easy.

     

    Summary:

    NXT- forking looks for me most easy to attack, but i didnt look fully into it up to know. Most of next problems seems to me solvable though combining it with some kind of proof of work.

    Masternodes looks quite nice. Most of the problems as far as i see them looks solvable to me. The two tier implementation of proof of work and masternodes looks quite elegant.

    Steems delegated proof of stake looks also quite elegant. In comparison to masternodes it looks more centralised, which has their pros and cons, currently i would favor a wider participation in block creation / transaction locking like masternodes have.

     

    Then there is also ethereums proof of stake proposal which i didnt look into it yet:

    https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735#.sysy5p4e9

    And finally here also the Tendermint proposal:

    https://cosmos.network/

  5. UPDATE:

    old nodes that are not aware of an higher existing tier can just continue to validate transactions as they always did. Updated nodes, that are aware of an higher tier, but do not have enough resources to be a full node on a higher tier, could if they want take part in the active enforcement of higher tear transactions in the following way:

    - they could download the full or a part of the current balances (unspent set) from higher tier nodes and block transactions / blocks that are not valid according to that

    - if they dont have the current balances they could ask higher tier nodes if the transaction is valid and block if not

     

    What is the trust model for that?

    At worst it would have the same trust model as now, because also now miners have the power to block transactions as long as a majority of the mining power agrees.

    Further the following could be done to increase the security:

    - lower tier nodes could verify, that the balance set is referenced from an block in the longest chain and therefore has at least the majority of the miners behind it

    - lower tier nodes could partially proof the validity of the balances and could denounce nodes that provide invalid data 

    - lower tier nodes could ask different higher tier nodes they trust if they agree on the current balances or validity of an higher tier transaction

  6. Hi all,

    here is a draft how we could use an multi tier blockchain that allows high transaction processing without compromising decentralisation.

    As always feels welcome to give feedback,

    Arcurus

     

    This proposal is based on this proposal, so good to read this first:

     

    How could a multi tier block chain look like:

    - the normal block would be called zero tier block

    - a block in the next tier is called tier one block

    - a block in the next tier after tier one is called tier two block

    - each tier block references the next tier

    - higher tiers could have increased block size and or faster block creation or other useful properties

    - the output of tier x transactions is marked to be spent by all according to the tier x-1 logic

    - so called manifestation transactions see above could be used to summarize what was happening in the higher tiers.

     

    What are the benefits?

    Though using a multi tier block chain architecture we would have the possibility to use different tiers for different purposes. Currently we face the problem that one single tier block chain cannot solve two contradicting properties like decentralizations vs transaction throughput. Naturally it can only be good according to one of these properties, or must compromise these properties. In a multi tier block chain, tier zero could be used to have good decentralization properties while an higher tear could be used to have an high transaction throughput. Naturally transactions in an higher tear would be less safe, but would be also less expensive. In short the more you pay the higher likely the tear your transaction is included and the more secure your transaction will be.

     

    Can this be implemented as on soft fork?

    Yes, this could be implemented as a soft fork the same way as outlined above in extended blocks.

×
×
  • Create New...