Bitcoin Forum
April 22, 2018, 06:52:03 AM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 ... 347 »
  Print  
Author Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer  (Read 447339 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 14, 2016, 08:21:44 PM
 #41

I will post a followup explaining my own idea for a pure PoS scheme.

I'm in the possibly advantageous position of knowing that PoS is a respectable way to secure a blockchain, but not actually knowing how anyone does it.  Therefore I'm starting with a blank mental slate, but approaching it from a mindset that says "how can I make this work?" rather than "can this be made to work?"

My idea is that, instead of having the PoS miners compete to find a hash that meets a particular target, said target being easier for large stakeholders than for smaller ones, why not just award the block to the PoS miner with the largest stake value?  Of course, the "stake value" cannot just be the account balance, otherwise the same account would win block after block after block, until spent or until another account achieved a higher value.  Moreover the winning miner could prevent that from happening simply by refusing to include in his blocks any transaction that would put a competing account over the value of his own.

I propose that "stake value" of an account be the time integral of the account balance since the last time that account won a PoS block, or the from the time of its creation, if it never has.  In addition to keeping track of an account's balance, therefore, we would also have to keep track of it's stake value.  We would not have to recalculate it every block, instead we could just record the block number when it was last recalculated, and recalculate every time the balance changes.

In order to generate one block per minute, quite regularly, I propose the following process.

At time x minutes and 00 seconds, each node will have (tentatively) chosen the previous block winner.  Let's assume for the sake of arguement that every node has chosen the same block.  This would be the situation after the first genesis block.

The next 40 seconds I call the refectory period.  No blocks timestamped during this period will ever be accepted by any node.  (Also no node will judge any block the winner, if it receives that block before its timestamp, though it might accept if it is otherwise acceptable, just in case the rest of the network decides to choose it anyway, which they might, if they receive it later.  A node could accept multiple competing blocks)

The next 20 seconds is the bidding period.  During this period, any account holder may generate and sign a block, (or start distributing a block generated earlier, though there will be no advantage in doing this).  Other nodes will accept it if its stake value is greater than any other block already received.  They may also accept it if it is lower, but it is still high enough that the node believes that it might win the global contest anyway. (It can never win the local contest because it doesn't have the greatest stake value known to the node.)  Nodes may also choose to reject (i.e. delete from memory) previously accepted blocks which it judges to no longer have a chance to win the contest.  However, nodes will only ever attempt to distribute the highest scoring block they know about.

At the end of the bidding period, each node chooses the winner.  Most likely every node will have chosen the same block, the one which globally has the highest stake value, and the next refectory period can begin like the last, only this time, that account will have a stake value of zero.  Sometimes the highest value block may not have reached every node, and on rare occasions, for example if the highest stake-value block was released close to the end of bidding, another block might be judged the winner on the majority of nodes, Call this block the global winner.

After another refectory period, the next round of bidding begins.  Each node submitting a block will chain it from what it thinks the winner of the last round was, but each accepting node will accept high scoring blocks from the other last round contestants.  The next block winner (as judged by each node) will be the highest scoring block across all the competing chains.

Because most submitted blocks will extend the chain of the previous global winner, it is likely that the next global winner will extend that chain.  Over time, the side chains will be extended by fewer and fewer blocks until no node considers them to be a winner, at which point they die.

Because this system doesn't care what the hash value is, there is no way to turn it into PoW.  It is pure PoS.  Thoughts?  Comments?  Criticisms?
1524379923
Hero Member
*
Offline Offline

Posts: 1524379923

View Profile Personal Message (Offline)

Ignore
1524379923
Reply with quote  #2

1524379923
Report to moderator
1524379923
Hero Member
*
Offline Offline

Posts: 1524379923

View Profile Personal Message (Offline)

Ignore
1524379923
Reply with quote  #2

1524379923
Report to moderator
1524379923
Hero Member
*
Offline Offline

Posts: 1524379923

View Profile Personal Message (Offline)

Ignore
1524379923
Reply with quote  #2

1524379923
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1524379923
Hero Member
*
Offline Offline

Posts: 1524379923

View Profile Personal Message (Offline)

Ignore
1524379923
Reply with quote  #2

1524379923
Report to moderator
1524379923
Hero Member
*
Offline Offline

Posts: 1524379923

View Profile Personal Message (Offline)

Ignore
1524379923
Reply with quote  #2

1524379923
Report to moderator
1524379923
Hero Member
*
Offline Offline

Posts: 1524379923

View Profile Personal Message (Offline)

Ignore
1524379923
Reply with quote  #2

1524379923
Report to moderator
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 14, 2016, 08:27:24 PM
 #42

I think if we use two signatures:

- the full signature for the integrity of the block
- and the PoS signature which is only there to check if the user was allowed to forge the block

By "forge" you mean "create", not "falsify".

So the PoS only directly validates the winner's public key.  The winner's signature validates the data block, and nobody else can steal the proof of work and claim it validates a different block because they will not be able to sign that block. Am I right?

What is to stop the block winner from signing two different data blocks?
Matory
Sr. Member
****
Offline Offline

Activity: 373
Merit: 250


View Profile
March 14, 2016, 08:31:33 PM
 #43

ELC ticker was since at 2013 and live now — https://bitcointalk.org/index.php?topic=766417.0
Please change the coin name!
aleksand
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000


ICO starting on 16th of April!


View Profile
March 14, 2016, 08:46:10 PM
 #44

ELC ticker was since at 2013 and live now — https://bitcointalk.org/index.php?topic=766417.0
Please change the coin name!
Lol, really. You can check at http://coinmarketcap.com/currencies/elacoin/
How soon ico will end? It will take really too long to wait untill all 100% of coins will be DISTRIBUTED.

▀███████████▀      ▄████
  ▀███████▀      ▄██████
    ▀███▀      ▄██████▀
      ▀      ▄██████▀
           ▄██████▀
         ▄██████▀
       ▄██████▀
     ▄██████▀
   ▄██████▀     
 ▄██████▀      ▄███▄
██████▀      ▄███████▄
████▀      ▄███████████▄
.ZPER.▀███████████▀      ▄████
  ▀███████▀      ▄██████
    ▀███▀      ▄██████▀
      ▀      ▄██████▀
           ▄██████▀
         ▄██████▀
       ▄██████▀
     ▄██████▀
   ▄██████▀     
 ▄██████▀      ▄███▄
██████▀      ▄███████▄
████▀      ▄███████████▄
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 14, 2016, 08:55:16 PM
 #45

ELC ticker was since at 2013 and live now — https://bitcointalk.org/index.php?topic=766417.0
Please change the coin name!

CEP?  The Coin of the Elastic Project.
poornamelessme
Hero Member
*****
Offline Offline

Activity: 672
Merit: 500


View Profile
March 14, 2016, 09:00:44 PM
 #46

ELC ticker was since at 2013 and live now — https://bitcointalk.org/index.php?topic=766417.0
Please change the coin name!

CEP?  The Coin of the Elastic Project.

If renaming, not so sure about that one. Coin of the Elastic Project doesn't exactly roll off one's tongue... and CEP doesn't automatically lead one to think of 'Elastic'.

Maybe just Elastic (ELA), Elastic Network (ELN), Elastic Token (ELT), or Elastic Project (ELP), etc. -- something that starts with E probably would be best. Although I guess one should make sure those letters aren't taken already.


         ▄▄▄██████████▄▄▄
      ▄███▀▀▀        ▀▀▀███▄
    ▄██▀  ▄▄██████████▄▄ ▀██▄
   ██▀ ▄██████████████████▄ ▀██
  ██  ██████████████████████  ██
 ▐█▌ ███████  ▄▄▄▄▄   ▄██████ ▐█▌
 ██ ▐███████▄████▀  ▄████████▌ ██
▐█▌ ████████▄▄▄▄   ▄▄▄▄███████ ▐█▌
 ██ ▐███████▄▄   ▄▄▄▄▄▄██████▌ ██
 ▐█▌ ███████▀  ▄█████▀ ██████ ▐█▌
  ██  █████▄▄▄▄▄▄▄▄▄▄▄▄█████ ▄██
   ██▄ ▀██████████████████▀ ▄██
    ▀██▄  ▀▀██████████▀▀  ▄██▀
      ▀██▄▄▄▄        ▄▄▄▄██▀
         ▀▀▀██████████▀▀▀

ZYPCOIN
           ▄█████████████▄
          ▐██▌          ██▌
         ▄▄▄▄▄▄▄▄▄▄     ██▌
     ▄█████████████     ██▌█▌
     ███████▀▀▀▀▀▀      ██▌██
    ▐█████▀▄█           ██▌█▌
    ▐█████▐██           ██▌██
    ██████▐██           ██▌█▌
    ██████▐██▌          ██▌██
   ▄██████▐███████▀███████▌
 ▄████████▄▀█████████████▀
▀█████████████▀
  ▀▀████████▀
      ▀▀██▀
   ▄█████████████▄
  ▐██          ▐██▌
  ▐██     ▄▄▄▄▄▄▄▄▄
▐█▐██     █████████████▄
██▐██      ▀▀▀▀▀▀███████
▐█▐██          ▐█▄▀█████▌
██▐██          ▐██▌█████▌
▐█▐██          ▐██▌██████
██▐██          ▐██▌██████
  ▐███████▀███████▌██████▄
   ▀█████████████▀▄████████▄
              ▀█████████████▀
                ▀████████▀▀
                  ▀██▀▀
scam confirmed
Hero Member
*****
Offline Offline

Activity: 616
Merit: 500


View Profile WWW
March 14, 2016, 09:06:02 PM
 #47

ELAhu akbar!

xxxgoodgirls
Legendary
*
Offline Offline

Activity: 1064
Merit: 1001


View Profile
March 14, 2016, 09:10:16 PM
 #48

ELC ticker was since at 2013 and live now — https://bitcointalk.org/index.php?topic=766417.0
Please change the coin name!

CEP?  The Coin of the Elastic Project.

If renaming, not so sure about that one. Coin of the Elastic Project doesn't exactly roll off one's tongue... and CEP doesn't automatically lead one to think of 'Elastic'.

Maybe just Elastic (ELA), Elastic Network (ELN), Elastic Token (ELT), or Elastic Project (ELP), etc. -- something that starts with E probably would be best. Although I guess one should make sure those letters aren't taken already.

ELP is taken, I'd pick ELA.

In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware. details https://libreboot.org/faq.html#intelme --- https://tehnoetic.com/laptops --- https://store.vikings.net/x200-ryf-certfied
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 14, 2016, 09:14:13 PM
 #49

What is to stop the block winner from signing two different data blocks?

The problem here is that if any part of data block is fed into the PoS hash, then that part can be used as a nonce to turn your PoS into PoW.  If any part of the data block is not fed into the hash, then that part can be modified to create a competing data block, and the winning stakeholder could sign both.  To avoid both problems, you need simultaneously to feed in all of the data block, and none of it.

Under my scheme as outlined about, you feed in all of it.  Sure the stakeholder could manipulate the block to create a different hash value, but this makes no difference, because the hash value is not significant.  If he tried to distribute two (or more) different blocks both signed by the same key, then each would have the same stake value and he would just be competing against himself.  Eventually one (or none) of those blocks will become the main chain, while the others would die.
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 14, 2016, 09:20:31 PM
 #50

Maybe just Elastic (ELA), Elastic Network (ELN), Elastic Token (ELT), or Elastic Project (ELP), etc. -- something that starts with E probably would be best. Although I guess one should make sure those letters aren't taken already.

Not ELT.  This is a coin, not a token.  I would favour ELN.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 14, 2016, 09:27:34 PM
 #51


The problem here is that if any part of data block is fed into the PoS hash, then that part can be used as a nonce to turn your PoS into PoW.  If any part of the data block is not fed into the hash, then that part can be modified to create a competing data block, and the winning stakeholder could sign both.  To avoid both problems, you need simultaneously to feed in all of the data block, and none of it.


He could indeed sign two different blocks with the same PoS signature. These two different blocks would however be only linkable to one certain previous block (note, the previous block's hash indeed is fed into the PoS hash). This way you can create many many "sub-chains" of length 1 of which of course only one will eventually survive. I see only the danger of an easy 0-confirmation attack, but maybe I just miss something basic here.

Let me first read your suggestion from above, after I have gotten myself a hot cup of coffee.
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 14, 2016, 09:28:06 PM
 #52

PEN - Project Elastic Network.

The demo could be TELA - Toy Elastic.

So we would have PEN and TELA.
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 14, 2016, 09:31:01 PM
 #53

He could indeed sign two different blocks with the same PoS signature. These two different blocks would however be only linkable to one certain previous block (note, the previous block's hash indeed is fed into the PoS hash). This way you can create many many "sub-chains" of length 1 of which of course only one will eventually survive. I see only the danger of an easy 0-confirmation attack, but maybe I just miss something basic here.

He could use multiple versions of the previous block as a nonce to win the next one.

This is actually the nightmare scenario.  Using the current data block is at least a strategy that all the (purportedly) PoS miners could use.  But only a winner of the previous block could use the win as leverage to win the next, and the next, and the next...
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 14, 2016, 09:38:35 PM
 #54

He could use multiple versions of the previous block as a nonce to win the next one.

Could we solve this issue by not feeding the previous block's hash into the current block's PoS hash
but the previous block's PoS hash (containing the last block's miner's signature as well as some other variable that varies deterministically from block to block such as the block height) itself? This should be invariant to any sort of changes to the previous block.


EDIT: So basically:

Current Block's PoS hash is the hash of the concatenation of
(Last Blocks Height, Last Blocks PoS Signature, Current Blocks Height, My PoS Signature)
and if this meets the target value we're done?
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 14, 2016, 09:42:19 PM
 #55


Could we solve this issue by not feeding the previous block's hash into the current block's PoS hash
but the previous block's PoS hash itself? This should be invariant to any sort of changes to the previous block.


Then we're back to the problem we have before.  The chain of successive PoWs each validate the previous, but there is nothing uniquely tying them to the data blocks.

You could try to forbid an account from winning consecutive blocks, but then Sybil.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 14, 2016, 09:54:43 PM
 #56

Quote from: Dazza

The next 40 seconds I call the refectory period.  No blocks timestamped during this period will ever be accepted by any node.  (Also no node will judge any block the winner, if it receives that block before its timestamp, though it might accept if it is otherwise acceptable, just in case the rest of the network decides to choose it anyway, which they might, if they receive it later.  A node could accept multiple competing blocks)

The next 20 seconds is the bidding period.  During this period, any account holder may generate and sign a block, (or start distributing a block generated earlier, though there will be no advantage in doing this).  Other nodes will accept it if its stake value is greater than any other block already received.  They may also accept it if it is lower, but it is still high enough that the node believes that it might win the contest anyway.  Nodes may also choose to reject (i.e. delete from memory) previously accepted blocks which it judges to no longer have a chance to win the contest.  However, nodes will only ever attempt to distribute the highest scoring block they know about.

At the end of the bidding period, each node chooses the winner.  Most likely every node will have chosen the same block, the one which globally has the highest stake value, and the next refectory period can begin like the last, only this time, that account will have a stake value of zero.  Sometimes the highest value block may not have reached every node, and on rare occasions, for example if the highest stake-value block was released close to the end of bidding, another block might be judged the winner on the majority of nodes, Call this block the global winner.

After another refectory period, the next round of bidding begins.  Each node submitting a block will chain it from what it thinks the winner of the last round was, but each accepting node will accept high scoring blocks from the other last round contestants.  The next block winner (as judged by each node) will be the highest scoring block across all the competing chains.

I absolutely love your approach. There are however two problematic parts about it, that I see and that would have to be settled out.

a) The fact that every node is allowed to submit a block during the bidding periodcould cause immense congestion in terms of network traffic.
Most likely, the moment the bidding period begins, there is no "highest value block yet". This regularly would cause all nodes to simultaneously broadcast their block as they think it is the highest so far.

b) We do not have synchronized clocks. In fact, clocks may drift away in the magnitude of minutes and we cannot assume that every node uses the same NTP server to sync its time. I see hard to solve synchronization issues here.
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 14, 2016, 09:55:52 PM
 #57

The next 20 seconds is the bidding period.  During this period, any account holder may generate and sign a block, (or start distributing a block generated earlier, though there will be no advantage in doing this).  Other nodes will accept it if its stake value is greater than any other block already received.  They may also accept it if it is lower, but it is still high enough that the node believes that it might win the global contest anyway. (It can never win the local contest because it doesn't have the greatest stake value known to the node.)  Nodes may also choose to reject (i.e. delete from memory) previously accepted blocks which it judges to no longer have a chance to win the contest.  However, nodes will only ever attempt to distribute the highest scoring block they know about.

Edited for clarity.
worthyou
Sr. Member
****
Offline Offline

Activity: 384
Merit: 250


View Profile
March 14, 2016, 10:03:59 PM
 #58

Is there any advantage for early investors on ico? If not what is the point of buying now instead of buying last minute?

schnötzel
Legendary
*
Offline Offline

Activity: 1106
Merit: 1000

Bitcoin is a bit**


View Profile
March 14, 2016, 10:08:55 PM
 #59

Is there any advantage for early investors on ico? If not what is the point of buying now instead of buying last minute?

All you need is here:

http://www.elastic.pro/crowdsale
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 14, 2016, 10:09:26 PM
 #60

a) The fact that every node is allowed to submit a block during the bidding periodcould cause immense congestion in terms of network traffic.
Most likely, the moment the bidding period begins, there is no "highest value block yet". This regularly would cause all nodes to simultaneously broadcast their block as they think it is the highest so far.=

Perhaps we could program the following heuristic:

1.  If I have a stake value greater than or equal to the previous winner, broadcast as soon as the bidding period starts.

2.  Otherwise if my stake value is x% of the previous winner, wait until there is only x% of the bidding time left.  Broadcast only if I have not yet received a better block.  Edited to add: apply the same heuristic to any higher value blocks I receive, in other words, If I receive a block before I think it ought to have been sent, wait until then before passing it on.

Quote
b) We do not have synchronized clocks. In fact, clocks may drift away in the magnitude of minutes and we cannot assume that every node uses the same NTP server to sync its time. I see hard to solve synchronization issues here.

I'm not an expert on NTP, but aren't most servers within a few seconds of real time?  So most nodes should be OK.  Those nodes using the wildly out-of-synch time are screwed anyway and could perhaps notice that "everyone else is using the same time, but different from me, so I'll correct myself".

We could perhaps tolerate a timestamp which is a few seconds into the future.
Pages: « 1 2 [3] 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 ... 347 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!