Bitcoin Forum
April 22, 2018, 09:04:43 PM *
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 54 55 ... 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 16, 2016, 12:43:13 AM
 #81

And I am working day and night to keep my promise to give the community a mini-blockchain with a basic PoS scheme (as for example used in NXT) to play with by tomorrow today (GMT). It is not that easy, but I think I can meet my deadline.

I'm certainly not working night and day.   Wink

I'm conscious of the fact that I also have an outstanding promise, namely to detail the attack on the section 2.4 PoW system, and suggest other ways to assure both buyers and miners that they will get their rewards.  However, I think at the moment, my time is better spend brainstorming what you're working on now, than thinking about what you won't be working on for a while.

Getting a coin up-and-running is the easy bit.  It's the right decision to do it first.
1524431083
Hero Member
*
Offline Offline

Posts: 1524431083

View Profile Personal Message (Offline)

Ignore
1524431083
Reply with quote  #2

1524431083
Report to moderator
1524431083
Hero Member
*
Offline Offline

Posts: 1524431083

View Profile Personal Message (Offline)

Ignore
1524431083
Reply with quote  #2

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

Posts: 1524431083

View Profile Personal Message (Offline)

Ignore
1524431083
Reply with quote  #2

1524431083
Report to moderator
1524431083
Hero Member
*
Offline Offline

Posts: 1524431083

View Profile Personal Message (Offline)

Ignore
1524431083
Reply with quote  #2

1524431083
Report to moderator
1524431083
Hero Member
*
Offline Offline

Posts: 1524431083

View Profile Personal Message (Offline)

Ignore
1524431083
Reply with quote  #2

1524431083
Report to moderator
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 16, 2016, 12:52:50 AM
 #82

I'm conscious of the fact that I also have an outstanding promise, namely to detail the attack on the section 2.4 PoW system, and suggest other ways to assure both buyers and miners that they will get their rewards.  However, I think at the moment, my time is better spend brainstorming what you're working on now, than thinking about what you won't be working on for a while.

I think both of these points are very important as they are the integral part of the coin we try to build here.
And yes, building the base variant of the coin is relatively easy. It is time consuming but a bit like an occupational therapy and not that sophisticated from the scientific point of view. However, it has to be made at some point.
Indeed, it is a lot of work to collect all the insights and ideas from the different papers (such as the mini-blockchain) and getting it all straight into a practically working piece of software, but the really interesting part will come then (actually you have already started brainstorming thoroughly about it). I totally agree.
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 16, 2016, 12:55:03 AM
 #83

This

b) The signature of a miner, that signs the previous block's PoS hash S

Is not consistent with this

Quote
b) The signature signing the PoS hash the full hash (?) of Block x (note, last block, not the current one)

Could you please clarify?

Quote
I am yet to understand how exactly we could PoW the PoS block here, assuming that we force a deterministic signature scheme and disallow any signer-injected randomness in the signature.

One of us is missing something, because I cannot see how you could possibly prevent a miner from PoW the PoS, without allowing a winner to sign two competing blocks which the system would then not be able to distinguish.

The person missing something could be me.  I await your clearer explanation.

If I turn out to be right on this matter, is this a previously-unrecognised vulnerability of NXT coin?
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 16, 2016, 01:03:11 AM
 #84

building the base variant of the coin is relatively easy. It is time consuming...

I still think you are gravely underestimating the sheer amount of programing which will be required for the market part of the project.  It will simply be too much for you to do in a reasonable time.  We're going to need more dakka... I mean, more programmers.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 16, 2016, 01:05:33 AM
 #85

This

b) The signature of a miner, that signs the previous block's PoS hash S

Is not consistent with this

Quote
b) The signature signing the PoS hash the full hash (?) of Block x (note, last block, not the current one)

Could you please clarify?

Strike the signing of the previous PoS hash. We sign the previous block's PoS signature.

Quote

One of us is missing something, because I cannot see how you could possibly prevent a miner from PoW the PoS, without allowing a winner to sign two competing blocks which the system would then not be able to distinguish.

The person missing something could be me.  I await your clearer explanation.

To recap,

Imagine we start with a Block x with:
a) H, the full hash which is the of the entire block's content
b) A PoS signature S
b) S, the PoS hash which is unique for the particular block and the PoS signature (not depending on data, but indeed on signature)

Now we mine a Block (x+1):
a) H, again the full hash
b) The signature signing the previous "PoS signature" of Block x (note, last block, not the current one)
c) Again this block has an own PoS hash which is unique for block and signature (not depending on data, but indeed on signature)

Every miner (or however you want to call him, maybe forger? or staker?) can only generate one (and only one) PoS signature for the current block. The last block's PoS signature is fixed, and the miner can only generate one (!!) signature for the current block. Varying the random number (r-value) for the current signature is not allowed. So we need a strong, deterministic and non-random signature scheme here.

As the current Block's PoS signature only depends on the last block's signature, we cannot PoW here by changing parts of the current block.

The PoS hash which checks if the PoS signature solved the block or not, i.e., the PoS hash is below a certain target value, must also depend only on values that cannot be freely changed "multiple times" by the miner (height, current signature, ...).


Dink
Member
**
Offline Offline

Activity: 72
Merit: 10


View Profile
March 16, 2016, 01:23:24 AM
 #86

Dazza, I saw a new version of POS on a coin that is not out yet.  It is a POS ..based on a proof of line..basically every one gets in line and gets their turn turn to stake, once you stake you go to the end of the line, dont kown what the variables they were planing on using.  Just thought i would base it on...more stuff to think about. 
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 16, 2016, 01:41:13 AM
 #87

To recap,

Imagine we start with a Block x with:
a) H, the full hash which is the of the entire block's content
b) A PoS signature S
b) S, the PoS hash which is unique for the particular block and the PoS signature (not depending on data, but indeed on signature)

Now we mine a Block (x+1):
a) H, again the full hash
b) The signature signing the previous "PoS signature" of Block x (note, last block, not the current one)
c) Again this block has an own PoS hash which is unique for block and signature (not depending on data, but indeed on signature)

By "PoS signature", do you mean the digital signature of the block winner, using his private key?  Or something else?

Quote
Every miner (or however you want to call him, maybe forger...

"Forge" has an unfortunate double-meaning in English.  It can mean "to create" or "to falsify", as in a forged document.  The double meaning, though unfortunate, is also apt, given the problem I see here.

Quote
or staker?) can only generate one (and only one) PoS signature for the current block. The last block's PoS signature is fixed, and the miner can only generate one (!!) signature for the current block.

He can only create one signature, but there is nothing tying H tit.  I think you intend for the block winner to also sign H (or the underlying data) with the same private key, which he could do, so that no other person could produce a competing data block (with a different H)  because they couldn't sign it with the right key.

But what is there to prevent the block winner from signing two or more competing Hs (or the underlying data) with the same (winning) key?

Or if you do not intend for the winner to sign H (or the underlying data), what ties H to the PoS signature?  What would prevent anyone at all for producing a competing data block and claiming that it was validated by that signature?

Quote
Varying the random number (r-value) for the current signature is not allowed. So we need a strong, deterministic and non-random signature scheme here.

This isn't the problem.  I'm not talking about this.

PoW only comes into it when you import H into the PoS signature.  Then the miner can diddle the data block all he likes, producing vast numbers of different Hs to use as his nonce.

It's one or the other.  Either you import H, allowing the miner to PoW the PoS by diddling the data block, or you don't import H, but then you fail to validate the data block at all.
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 16, 2016, 01:50:35 AM
 #88

Dazza, I saw a new version of POS on a coin that is not out yet.  It is a POS ..based on a proof of line..basically every one gets in line and gets their turn turn to stake, once you stake you go to the end of the line, dont kown what the variables they were planing on using.  Just thought i would base it on...more stuff to think about. 

What is to stop an attacker DOSing the system, by creating a million sybils who all get in line together, and go AWOL when it's time from them to create a block?  You could allow the next million-and-one consecutive stakers to submit proofs, but all that does is self-DOS the system with a proof-flood, without any help from an attacker.

Anyone can come up with a PoS system that they can't break (except me, apparently).  That doesn't mean that it is secure.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 16, 2016, 02:00:55 AM
 #89

Quote
If I turn out to be right on this matter, is this a previously-unrecognised vulnerability of NXT coin?

I more and more get the feeling that you indeed found a previously-unrecognised vulnerability of NXT coin.

Can this issue possibly be mitigated by enforcing uniqueness of a PoS signature, i.e., one PoS signature can only be used to sign one block; subsequent blocks get rejected?

EDIT: Darn, you could MITM the block signature easily.
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 16, 2016, 02:16:09 AM
 #90

Quote
If I turn out to be right on this matter, is this a previously-unrecognised vulnerability of NXT coin?

I more and more get the feeling that you indeed found a previously-unrecognised vulnerability of NXT coin.

As I said, it's one or the other.  Have a look at the code (which you're doing anyway), figure out which it is, and if there's a bug -bounty, I'll split it with you.   Grin

Quote
Can this issue possibly be mitigated by enforcing uniqueness of a PoS signature, i.e., one PoS signature can only be used to sign one block; subsequent blocks get rejected?

Better would be to reject all signed blocks, if more than one is detected.  Otherwise the risk is that different nodes accept different versions of that block.

But then you have a DoS.  The malicious winner waits until his PoS is deep in the blockchain before injecting the bogus competitor block.  Depending upon how the system reacts, he might even be able to leverage this into a sidechain attack.  Suppose that, as soon as he wins a block, he starts constructing his sidechain from the previous block using sybils.  Then at an appropriate point he injects the bogus block, invalidating the main chain and leaving his chain supreme.
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 16, 2016, 02:19:54 AM
 #91

EDIT: Darn, you could MITM the block signature easily.

How would you do that?

I'm thinking that, if all we have is a DoS, then perhaps we could tolerate it.  The more I think about sidechain attacks, the less they look any more dangerous than DoS anyway., (except to nodes whose only peers are attackers, but those nodes are screwed anyway.)
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 16, 2016, 02:24:51 AM
 #92

EDIT: Darn, you could MITM the block signature easily.

How would you do that?

I'm thinking that, if all we have is a DoS, then perhaps we could tolerate it.  The more I think about sidechain attacks, the less they look any more dangerous than DoS anyway., (except to nodes whose only peers are attackers, but those nodes are screwed anyway.)

Yes, you're right. This would be a (fairly easy to pull off) DoS attack. Not more, not less.
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 16, 2016, 02:38:01 AM
 #93

Yes, you're right. This would be a (fairly easy to pull off) DoS attack. Not more, not less.

So perhaps the NXT devs already know about this, and tolerate it.

I'd still like to have a go at revising my earlier plan to defeat the attack I found against it.  Who knows?  I may yet fulfill Schneier's Law by coming up with a security system I can't break.  Cheesy
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 16, 2016, 02:45:27 AM
 #94

I'd still like to have a go at revising my earlier plan to defeat the attack I found against it.  Who knows?  I may yet fulfill Schneier's Law by coming up with a security system I can't break.  Cheesy

 Cheesy Let's do it then. I would need a few hours sleep, however. I am awake for over 20 hours now.
I hope so see you tomorrow where I will try to focus only on your alternative PoS approach. I still like it a lot.
Dazza
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 16, 2016, 06:15:03 AM
 #95

Cheesy Let's do it then. I would need a few hours sleep, however. I am awake for over 20 hours now.
I hope so see you tomorrow where I will try to focus only on your alternative PoS approach. I still like it a lot.

I'll need to go to bed soon too.  But here we go:

As I said earlier, side-chain attacks - even the notorious 51% attack - are really just DoS attacks, so long as each node 1.  Rejects outright any side-chain that suddenly appears, which forks from before a block already classed as confirmed, and 2.  Refuses to class as confirmed any block after the fork of any live side-chain.  As long as you take both precautions, the attacker cannot double-spend, even if his chain eventually wins.  What the attacker can do, is delay confirmations until the fork is resolved.  Also, if his chain wins, he can shut out the transactions of his choice for as long as continues to be able to shut honest PoS miners out of the chain.  Both of these are DoSs.

When reading the following be careful to distinguish between the Stake Value (SV) of an account (ASV), the SV of a block (BSV), and the SV of a chain (CSV).  These will all have different definitions.  There will be two kinds of PoS, those that come with an associated block (PoS+B) and those that don't (PoS-B).  I'm also not going to consider timing issues as my goal here is just to get the idea across.

Assume that we want to regard as confirmed any block once it is N blocks deep into the blockchain.

My new idea is similar to my old one, in that for each block, there is a refectory period followed by a bidding period.  As before, each node discards any invalid PoS (i.e., those that violate the protocol, or those that do not extend a live chain) on sight, along with its block if it has one, and for each live chain, if it receives more than one valid PoS+B extending that chain, it regards the block with the highest ASV as the (local) winner.  It also keeps track of every other (valid) PoS - with or without block - it receives.  (It could discard the blocks of losing PoS+B, so long as it has a way to recover them from other nodes, if necessary.)  Nodes should discard or reject a PoS-B whenever it has decided to retain at least the PoS of a PoS+B from the same account.

At the start of the bidding period, a node should launch a PoS+B, for any account it controls with ASV greater than x% of the ASV of the account it regards as having won the last block.  Because ASVs are likely to obey Zipf's law, x could probably be set quite low without causing flooding.  Other nodes may have a different view of the winner of the last block, so a PoS+B might legitimately be launched, but rejected by other nodes who do not think its ASV is high enough.  (Nevertheless, a node should retain an otherwise valid PoS+B from an account it judges to have insufficient ASV for as long as it is the highest ASV PoS+B it has seen.  As soon as it sees another with a higher value, it can discard the lower one.)

In addition, the node should try to create a PoS-B for every account it controls with ASV > 0, including accounts for which it has launched PoS+B.  (The duplication is necessary because, as stated above legitimately submitted PoS+B may be rejected by other nodes due to insufficient ASV.) Unlike PoS+B, PoS-B will have to pass a hash value test which depends upon the account's ASV as with NXT.  If successful, these are also launched at the start of bidding.  Valid PoS-B are never rejected on grounds of insufficient ASV.  Finally, as a last resort, if a node has neither launched a block nor received a (valid) one (including otherwise valid blocks from accounts with insufficient SV) then it should launch a PoS+B for its highest SV account according to the delay schedule described in my previous suggestion.

All launched PoS (both PoS+B and PoS-B) should extend the chain with the greatest CSV, according to the launching node.

The end result of all of this, is that so long as a node controls at least one account with ASV > 0, there will be at least one chain extended by a PoS+B.  Any chain not so extended dies.  Also a chain dies if it's CSV is less than y% of the CSV of the winning chain.

Apart from the addition of PoS-B, The new scheme differs from the previous in that an account's ASV is no longer the time integral of its balance.  Instead it is equal to the lowest balance that the account has had during the last N blocks.  An account that was created or which has won a block fewer than N blocks ago has an ASV of zero.

The block extending a chain has a BSV equal to it's own ASV plus the ASV of all other PoS+B and PoS-B extending the same chain. Call these other contributors of ASV to the BSV "collateral support".  No account's ASV is counted more than once in the past N blocks, so if any of the PoS, including the winning PoS+B has already contributed collaterally to the BSV of an earlier block in the chain, then it is not counted again.  Nor, if a block is added to a collateral supporter, does the new block add to the collateral support.  In other words, collateral support is given to sisters, not aunts.  The CSV is the sum of the last N blocks' BSVs.

The idea behind collateral support is that the main chain will benefit from honest PoS more than any side-chain, including a side-chain being built by an attacker.  (If the attacker's chain benefits more, then it is the main chain by definition.)  Moreover an attacker can gain nothing by diverting his resources into his own collateral sybils, since this will just take away ASV from his winning blocks.  This is a zero-sum game for him.  PoS-B allows every account-holder with any ASV at all a chance to contribute collaterally to blockchain security, though they can never win a block unless their ASV is enough to allow them to launch a PoS+B.  Every PoS, with or without block, will need to has all the PoW supporting it's predecessor.

To summarise:  PoS+B need to meet an ASV threshold, but not a hash threshold.  BoS-B need to meet a hash threshold, but no ASV threshold. Note that the attack I describe above is defeated.  A PoS miner cannot PoW his PoS+B because there is no hash target to meet.  Neither can he PoW his PoS-B because there is no block to diddle.

If a fork persists longer than N blocks, then we increase N by 1 per block so that it always covers at least as far back as the fork point.  To maintain the fork, an attacker will have to bring ever more resources to bear.  Or increase his chain's CSV past that of the main chain, at which point it takes over as the main chain.  To do this, he will need to own N account each with a higher balance than anyone else.  If we ever see the same N accounts winning over and over, we could increase N even if we don't see a fork.

Shit it's six-forty in the morning.
Mrboot
Legendary
*
Offline Offline

Activity: 1036
Merit: 1000



View Profile
March 16, 2016, 08:13:02 AM
 #96

Hey dazza,

Thanks for the explanation i know what PoS does, PoW, PoS, Dpos im know to them i just wondered what the miniblocks were Wink

Sounds all very interresting and i might even invest some more but first i hope lannister can answer something or any other dev.

What will happen to the rest of the coins will they be burned ? And if there burned will the coin reward be adjusted to that ?
So the inflations isnt like super high cause now around 70 btc are invested x max 8k so that means 560000 coins so far.
Now on the github there is a coin reward of 100 coins a block seems pretty high now or will this all be adjusted ?

Or will it be split across the other investors based on time of investment ? (in my opinion a better option cause its easier to be distributed
in a later phase)

Cause i do wanna support but i really dont wanna get burned cause i do so Wink, hope you guys understand.

Hope to hear from you all.

Bgjjj2016
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250

Ben2016


View Profile
March 16, 2016, 08:23:32 AM
 #97

Hi Lannister,

I love your project and wish you the best. Yesterday, after reading your project, I was so excited that I sent 0.5 BTC to your address but , , ,unfortunately not reading the whole thing, via my BTCC exchange account.
I have screen shots of every step. Please advise me if you could do anything.
Today, I sent 0.75 BTC to your project via my Coinbase wallet about two hours ago and still don't see it on the GitHub records.

I appreciate your time and input.

Ben

My " I want that Old Toyota Camry very bad" BTC Fund :1DQU4oqmZRcKSzg7MjPLMuHrMwnbDdjQRM
Join the Elastic revolution! Elastic Network: The Decentralized Supercomputer 
ELASTIC WEBSITE|ANNOUNCEMENT THREAD|JOIN THE SLACK
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 16, 2016, 08:23:49 AM
 #98

What will happen to the rest of the coins will they be burned ? And if there burned will the coin reward be adjusted to that ?
So the inflations isnt like super high cause now around 70 btc are invested x max 8k so that means 560000 coins so far.
Now on the github there is a coin reward of 100 coins a block seems pretty high now or will this all be adjusted ?

Or will it be split across the other investors based on time of investment ? (in my opinion a better option cause its easier to be distributed
in a later phase)

There will only be max 5 million coins in circulation.
If not all of them are given away in the next 23023 bitcoin blocks they will most likely be just distributed among all those who at that point have ELC ... proportionally. So, simple case, imaging only two users have ELC, user 1 has 5 ELC user 2 has 20 ELC, then after the distribution of the remaining ELC they would end up with user 1 having 1M and user 2 having 4M.

Also, there will be no block reward so no inflation. Coins will circulate either by contributing work (solving these PoW blocks that we talked about and that do not secure the blockchain themselves) or by collecting fees (generating PoS blocks which are meant to secure the blockchain).

Not sure what is in the current github, but clearly not the PoS-mini-blockchain coin that I am currently working on. I will release my pending work today, however, so everyone can test a bit.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1134
Merit: 1142



View Profile
March 16, 2016, 08:25:14 AM
 #99

Today, I sent 0.75 BTC to your project via my Coinbase wallet about two hours ago and still don't see it on the GitHub records.

I appreciate your time and input.

Maybe I can help,
check: https://raw.githubusercontent.com/elastic-project/genesis-block/master/genesis-block.json
and scroll to the very bottom. There it is.  Cool
Bgjjj2016
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250

Ben2016


View Profile
March 16, 2016, 08:35:25 AM
 #100

Thank you so much  Evil-Knievel. I was looking at the top of the list  Grin

My " I want that Old Toyota Camry very bad" BTC Fund :1DQU4oqmZRcKSzg7MjPLMuHrMwnbDdjQRM
Join the Elastic revolution! Elastic Network: The Decentralized Supercomputer 
ELASTIC WEBSITE|ANNOUNCEMENT THREAD|JOIN THE SLACK
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 54 55 ... 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!