Bitcoin Forum
June 25, 2019, 02:40:42 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
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 56 57 58 59 60 ... 346 »
  Print  
Author Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer  (Read 449648 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.
dulinxu
Sr. Member
****
Offline Offline

Activity: 363
Merit: 250


View Profile
March 20, 2016, 12:03:21 AM
 #181

What is the consensus of the elastic network?

TERRA - Bring profits to support community, starting from cross-border payment ❘|❘ ICO ❘|❘ DISCUSSION

Mine RVN and with 0% mining fees and get paid in BTC, ETH, XMR or RVN.

www.cudominer.com Get Cudo Miner
Auto coin switching, third-party miners, overclocking and remote management (Win/Linux)
Run from a USB stick or install from an ISO image (Linux)
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1561430442
Hero Member
*
Offline Offline

Posts: 1561430442

View Profile Personal Message (Offline)

Ignore
1561430442
Reply with quote  #2

1561430442
Report to moderator
Dazza
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
March 20, 2016, 08:06:32 AM
 #182

What is the consensus of the elastic network?

Not sure I understand the question.  If you are asking what people think of the project, read the threads.  If you are asking what the word "consensus" means in a technical sense, it would be, very roughly "the data distributed throughout the network which is known to and agreed by every or almost every node".

Not sure if that helps.
jeffthebaker
Legendary
*
Offline Offline

Activity: 1442
Merit: 1034


View Profile
March 20, 2016, 07:01:24 PM
 #183

This is an incredibly ambitious project... I like it. I'm not usually one to donate for these types of things, but I see potential in Elastic. Put down .05 Smiley Is there a timeframe as to when the project will go live?
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
March 20, 2016, 07:13:31 PM
 #184

This is an incredibly ambitious project... I like it. I'm not usually one to donate for these types of things, but I see potential in Elastic. Put down .05 Smiley Is there a timeframe as to when the project will go live?

I think the deadline is bitcoin block 425920 which we all try to meet Wink
jeffthebaker
Legendary
*
Offline Offline

Activity: 1442
Merit: 1034


View Profile
March 20, 2016, 08:05:36 PM
 #185

This is an incredibly ambitious project... I like it. I'm not usually one to donate for these types of things, but I see potential in Elastic. Put down .05 Smiley Is there a timeframe as to when the project will go live?

I think the deadline is bitcoin block 425920 which we all try to meet Wink

Oh, ok. So it is just a matter of when all the funding has been donated?
nihilnegativum
Sr. Member
****
Offline Offline

Activity: 435
Merit: 250


––Δ͘҉̀░░


View Profile WWW
March 20, 2016, 08:42:00 PM
 #186

You need less time to launch the collateral PoS (is "collateral" the best word for this?  How about "subsidiary", "auxilliary", or "secondary"?), because there is no need to delay them, you are voting for your favoured chain, not your favoured block.  (But why not favoured block?  Favoured chain was just my original idea), and you don't need to see the other votes before deciding.
Wouldn't voting for your favoured block mean that the system would be in a continous state of soft forking, a kind of *khm* elastic system?
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
March 20, 2016, 08:58:53 PM
 #187

Quote from: Dazza
Before I post my revisions, let's touch base on the NXT scheme.  My understanding is that, regardless of stake, the first valid PoS block received by a node which meets the target is the winner.  It's just that the target is harder, and in general will be met later for small stakes than large ones.  If a node receives a valid block, before it has launched its own, then it won't launch.  I would imagine that in such a scheme, relatively few blocks launch, but if two are launched near simultaneously (or which become valid near simultaniously) in distant parts of the network, then the likelihood of a fork with both branches being built on is high.  How do you propose to eliminate side-chains?

I think we can avoid this problem by defining the "longest chain" as the chain with the greatest cumulative difficulty and not by its height. It is highly unlikely (like 1 in 2^64 with our uint64_t difficulty) that two chains evolve from one block which have the same cumulative difficulty. This results from the fact that we submit blocks only at a point in time when the target is equal to the hash which has a collosion probability of 1/2^64.

If such forks occur (and yes, i think they will occur frequently), it is therefore quite easy to let the chain with the higher cumulative difficulty survive and let the other one die.




I will comment on your method soon. I am rereading it once more.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
March 20, 2016, 10:10:17 PM
Last edit: March 21, 2016, 11:22:44 AM by Evil-Knievel
 #188

I will rephrase your method quickly with my own words just to make sure I got everything right. Questions are inline.

First, we have:

- ASV = Account Stake Value: It is equal to the lowest balance that the account has had during the last N blocks.
An account that was recently created or which has won a block fewer than N blocks ago has an ASV of zero.

- BSV = Block Stake Value: The BSV of the block extending a chain equals to it's own ASV plus the ASV of all other PoS+B and PoS-B extending the same chain (in the future or in the past? Is it just the cumulative ASV up to "now"?). No account's ASV is counted more than once in the past N blocks.

- CSV = Chain Stake Value: The CSV is the sum of the last N blocks' BSVs. (did I get it correctly that we have sums of sums of ASV's? Counting older ASV's more often then newer?)

Then, we have two different "proof of stakes":

- PoS+B = PoS with associated block (i.e., including and confirming transactions)
- PoS-B = PoS without associated block

Now starts the so called so-called voting period:

- Nodes broadcast a PoS+B block for each of their accounts A where ASV(A)>x% * OLD_WINNER_ASV, that is, the ASV of account A is x% of the ASV of the winner of the last block or higher.
- Additionally, each Node broadcasts an PoS-B (here, without a block, i.e., without confirming any transactions) for each of their accounts A where ASV(A)>threshold. The threshold is fixed and no hash target has to be met.

Then this happens


Quote
All launched PoS (both PoS+B and PoS-B) should extend the chain with the greatest CSV, according to the launching node. (not sure I get that: all valid blocks extend that chain? Not just the "best" one? Or is it rather one best PoS+B and one best PoS-B? I fear I am not 100% aware of what exactly is added to the collateral and what is extending the chain. Also, is the collateral persistent, or is it just for the voting phase?)

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.

So essentially, at least from what I understand, we no longer rely on any hash. As the hash was the only random factor in the scheme we now have a deterministic order who from a subset of N "online" users will win which block.

Also, I an not yet fully sure how the ASV will be "reaccumulated" after it was dropped to 0 upon creation of a new block. Will the ASV recover fully after N blocks have passed?
If so, this could leave an attacker the possibility to create N high-stake account and winning blocks with them "round robin".

Edit ... just saw, you already thought of that

Quote
...let M be the number of blocks back to the earliest live fork point, or M=N if larger.  

I have a different way to prevent the same N accounts winning over and over again.  For any given chain, order the PoS+B trying to extend it by ASV.  Then the one with the Highest ASV wins straight away so long as it hasn't already won in the last M blocks. (This would indicate, that in this change, the ASV does not drop to 0 after a block has been launched?)  Else if it won n blocks ago with n<=M, multiply its ASV by n/N, and move on to the next.  If the PoS+B with the next highest ASV hasn't won in the last M or 2N blocks (whichever is greater), then it wins straight away.  Else if it won n<max(M,2N) blocks ago, multiply its ASV by n/2N and move onto the next.  For the PoS+B with the third highest ASV, repeat the procedure using M and 3N and so on.

If no block wins straight away choose a block which has won the least number of times during the last M blocks.  Usually this number will be zero.  If there are several blocks tying on this metric, use the modified ASV as the tie-breaker.

With this scheme, larger stakes will win the block more often, but, so long as there is an alternative, never more than once since transaction confirmation or the oldest live fork point.  Smaller stakes get to win occasionally.

Sorry if I get that wrong, bit don't we have the same problem here? Its just not that you need N accounts, but M accounts (which is less actually, as M<=N?)



Apart from that: my respect, this is a very nice and well thought approach. I think I will have to reread it like 3 or 4 more times to fully understand it  Wink  I will try to wrap it up in pseudo code once I have understood everything so we get a basic idea how we could code that.


EDIT: Just saw that you have found even more attacks with those N accounts and that you are already addressing them  Wink

Quote
Step 1.  Normalise each candidate's ASV by dividing by the largest ASV of any of the last N block winners.  This will not affect their rankings in any way.  From now on, when I refer to a candidate's ASV, it is the normalised value I'm talking about.

Step 2.  Iterate through the candidates in decreasing order of ASV.  For each candidate, if the account last won more than max(M,N/ASV), or if it has never won, it wins; exit.  Otherwise multiply the ASV by the number of blocks to the last win.  Use this figure in the tiebreaker described in step 3.

Step 3.  If no candidate won during step 2, then the winner is the candidate that has won the least number of times during the last M blocks.  If there is a tie, then use the figure calculated in step 2 as a tiebreaker.



There is still a strange, though not necessarily undesirable property about this system.  Sometimes more stake can hurt an attacker.  For example, suppose the same honest accounts are staking throughout.  An attacker with N accounts each with equal balances greater than the highest-value honest stake would win every block forever (or until a non-staking account with a higher balance decided to start staking)  If these N accounts were the N highest, the attacker could permanently shut out transactions of his choice, including any transaction that might enable another account to compete.

But it would be really obvious that he was doing this.  So let's suppose that the attacker had some more funds, and randomly increased the balances of some of his accounts, then he would no longer prevent accounts he doesn't control from winning the occasional block.

Maybe its just because its sunday midnight, but I don't see the point why increasing his amounts would break his monopole. Could you please explain that in 2 lines?
What also came to my mind: what he could also do is to move the funds to a different account the moment he has found a block. This of course would lock his new account down for the next N blocks (until the ASV is mature) but allowing him then to mine a block with a new "identity" without any "past". He just needs enough "coins in the buffer" to pull it off successfully. Calibrated correctly, every block a new account (belonging to the attacker) with a sufficiently high ACV wins.

I.e., Assuming C coins is enough to win a stake and N>M, then the attacker needs (N+2)*C coins of which N*C cannot be used as they need N blocks to get mature (we call them coins-in-the-queue), and 1*C of them are used to "be sent to a different account" one block after they staked a block, and 1*C are winning the current block.
xxxgoodgirls
Legendary
*
Offline Offline

Activity: 1092
Merit: 1001


View Profile
March 20, 2016, 10:19:21 PM
 #189

Nice suggestion, I support it! Although I wouldn't call them workers but I'd rather refer to their computational tasks.

What would you call them, then?

computrons, calculators? I don't really know. Smiley

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
xxxgoodgirls
Legendary
*
Offline Offline

Activity: 1092
Merit: 1001


View Profile
March 20, 2016, 10:36:13 PM
 #190

Giving the complete decentralized taste of the project, wouldn't be better if the funds will be spent following a sort of consensus through ELC holders (something like the decentralized budget system in dash - being the ELC stash the collateral)?
I have nothing against Lannister, he looked to me as a cool and honest guy, but I believe there is still some risks due a single entity.
I mean, as far as I understood how elastic is going to work, funds will be blocked forever if Lannister disappears.
It's a random thought, tho, not a criticism.

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
ImI
Legendary
*
Offline Offline

Activity: 1946
Merit: 1019



View Profile
March 20, 2016, 10:44:12 PM
 #191

This is an incredibly ambitious project... I like it. I'm not usually one to donate for these types of things, but I see potential in Elastic. Put down .05 Smiley Is there a timeframe as to when the project will go live?

I think the deadline is bitcoin block 425920 which we all try to meet Wink

i see a "percentage of coins distrubuted"  on the website. what happens if 100% is met before block 425920?
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
March 20, 2016, 10:45:18 PM
 #192

Giving the complete decentralized taste of the project, wouldn't be better if the funds will be spent following a sort of consensus through ELC holders (something like the decentralized budget system in dash - being the ELC stash the collateral)?

This is a very good idea! A few years ago, I heard some talk at a conference about "decentralized democracy"  Cheesy  Basically, a "proposal" is put online and the voters find a decision (not a full consensus though) by some fancy metric. I would highly appreciate something like that. The hard part will be, as I think, to also "spend" the money in a decentralized way.

The workflow would need to be something like this:
- Someone has a great idea, finds someone to do that idea for 5 BTC and creates a transaction paying those 5 BTC.
- Now people must decide whether they support that or deny that. Usually, we would require the users to sign the transaction if they support it. But of course we want to make it depending upon the amount of ELC they hold, so high rollers have more to say. This again is highly problematic and I would love to see someone solve it using pure bitcoin scripts. How can you make one signature weigh more than others).
- Anyway, at this step somehow the transaction is signed and pushed to the network.

If step 2 cannot be made automatic, then we again have some third party involved.  Undecided  

I think, if someone was able to solve such issues with pure bitcoin, he would deserve one hell of a bounty.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
March 20, 2016, 10:46:06 PM
 #193

This is an incredibly ambitious project... I like it. I'm not usually one to donate for these types of things, but I see potential in Elastic. Put down .05 Smiley Is there a timeframe as to when the project will go live?

I think the deadline is bitcoin block 425920 which we all try to meet Wink

i see a "percentage of coins distrubuted"  on the website. what happens if 100% is met before block 425920?

Then, the ELC giveaway stops immediately. All other donations that were received would be returned.
ImI
Legendary
*
Offline Offline

Activity: 1946
Merit: 1019



View Profile
March 20, 2016, 10:49:34 PM
 #194

This is an incredibly ambitious project... I like it. I'm not usually one to donate for these types of things, but I see potential in Elastic. Put down .05 Smiley Is there a timeframe as to when the project will go live?

I think the deadline is bitcoin block 425920 which we all try to meet Wink

i see a "percentage of coins distrubuted"  on the website. what happens if 100% is met before block 425920?

Then, the ELC giveaway stops immediately. All other donations that were received would be returned.

ok. thx!
deadpoolx
Hero Member
*****
Offline Offline

Activity: 560
Merit: 500



View Profile
March 21, 2016, 12:53:02 AM
 #195

I have some doubts here. I'm thinking if Elastic Project (Decentralized Supercomputer as you said) has some relation with Gridcoin, once Gridcoin Project directs the computational power to solve scientific problems, integrated with BOINC (Berkley Open Infrastructure for Network Computing).

What are the Elastic Project improvements, in that case?
Dink
Member
**
Offline Offline

Activity: 74
Merit: 10


View Profile
March 21, 2016, 01:14:02 AM
 #196

Giving the complete decentralized taste of the project, wouldn't be better if the funds will be spent following a sort of consensus through ELC holders (something like the decentralized budget system in dash - being the ELC stash the collateral)?

This is a very good idea! A few years ago, I heard some talk at a conference about "decentralized democracy"  Cheesy  Basically, a "proposal" is put online and the voters find a decision (not a full consensus though) by some fancy metric. I would highly appreciate something like that. The hard part will be, as I think, to also "spend" the money in a decentralized way.

The workflow would need to be something like this:
- Someone has a great idea, finds someone to do that idea for 5 BTC and creates a transaction paying those 5 BTC.
- Now people must decide whether they support that or deny that. Usually, we would require the users to sign the transaction if they support it. But of course we want to make it depending upon the amount of ELC they hold, so high rollers have more to say. This again is highly problematic and I would love to see someone solve it using pure bitcoin scripts. How can you make one signature weigh more than others).
- Anyway, at this step somehow the transaction is signed and pushed to the network.

If step 2 cannot be made automatic, then we again have some third party involved.  Undecided  

I think, if someone was able to solve such issues with pure bitcoin, he would deserve one hell of a bounty.

Why could not something like this be coded into a wallet.  The total number of ELC is fixed so someone submitting a vote through a wallet would automatically be sending his percentage vote via his publickey.  If he has multiple wallets they would be eligible as well.  I would disallow amounts held by exchanges, and other shady dealings.
davide72
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002



View Profile WWW
March 21, 2016, 01:52:32 AM
 #197

any bounty for translating? thanks

              ███
             █████
            ███████
           █████████
          ███████████
         █████████████
        ███████ ███████
       ███████   ███████
      ███████     ███████
     ███████       ███████
    ███████         ███████
   ███████           ███████
  ███████             ███████
 █████████████████████████████
███████████████████████████████
.
M!RACLE TELE
...BRINGING MAGIC...
...........TO THE TELECOM INDUSTRY...........

██
██
██
██
██
██
██
██
██
██
40% Biweekly Rewards
▬▬▬   Calls at €0.2   ▬▬▬
Traffic from €0.01 worldwide

██
██
██
██
██
██
██
██
██
██
      ██         ██     
        ▀▌     ▐▀       
       ▄██▄▄▄▄▄██▄      
     ▄█████████████     
   ▄█████████████████▄   
  ██████▄██████▄██████  
 ▐█████████████████████▌
  ██████▀███████▀██████ 
  █████   █████   █████  
  █████████████████████  
  █████████████████    
    ███████████████    
 ▀██▄ ████████████  ▄██▀
      ▀██▀   ▀██▀   
       ▄█       █▄
ANN
Lightpaper
Bounty
Facebook
Twitter
Telegram
Enema
Sr. Member
****
Offline Offline

Activity: 430
Merit: 250



View Profile
March 21, 2016, 02:35:30 AM
 #198

Watching closely!

Sam123
Hero Member
*****
Offline Offline

Activity: 980
Merit: 502


View Profile
March 21, 2016, 05:10:55 AM
 #199

Hi,

Will it be possible to send BTC from Coinbase Account to Elastic project?
Or do I need to transfer first the BTC from coinbase to a wallet (example blockchain.info) then to Elastic project (to get the private Key)
The address to send will be 3Q2aKEGFTKDw3hghsBifXp39CZVMtZukxn correct?
Thanks,
allwelder
Legendary
*
Offline Offline

Activity: 1498
Merit: 1000



View Profile
March 21, 2016, 07:09:41 AM
 #200

@E-K
How do you solve the so called 'Nothing @ Stake' problem if with NXT style POS(i did not much clear about how NXT slove this also)?
Thanks.
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 56 57 58 59 60 ... 346 »
  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!