Bitcoin Forum
January 19, 2018, 12:30:44 AM *
News: Electrum users must upgrade to 3.0.5 if they haven't already. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 »  All
  Print  
Author Topic: This message was too old and has been purged  (Read 12327 times)
CB_project
Member
**
Offline Offline

Activity: 86


View Profile
February 24, 2016, 08:34:29 AM
 #21

source code available after launch?

Of course, everything will be open source! Even the software that manages the crowdsale and the code for the website is open source.
Please check the website or the first post in this thread for the links to all GitHub repositories.

thanks for the answer and good luck
"Your bitcoin is secured in a way that is physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter a majority of miners, no matter what." -- gmaxwell
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Cryptorials
Hero Member
*****
Offline Offline

Activity: 655


Cryptorials.io


View Profile
February 24, 2016, 08:42:46 AM
 #22

Quote
I would suggest that we allow for changes in the money supply

Changes in the money supply are in almost all cases the beginning of the end.
Increasing the money supply disadvantages everyone that holds coins at that time.

Yes you are right.

The baseline of performing PoW for other coins should be enough to give work with reasonable rewards for miners anyway.

I was just trying to look at Tau chain and I can't even find any explanation of how they secure consensus or whether their 'proof of code execution' is involved, and I'm not capable of finding out from reading the code. I wonder if perhaps they have been so busy discussing logical ontologies that they have allowed the security of the Agoras coin to take a back seat

Evil-Knievel
Legendary
*
Offline Offline

Activity: 1106



View Profile
February 24, 2016, 09:39:53 AM
 #23

This message was too old and has been purged
Dazza
Jr. Member
*
Offline Offline

Activity: 56


View Profile
February 24, 2016, 09:41:31 AM
 #24


Quote
I claim that the buffer will be written at a more or less constant rate.  In general, statements which change more variables will also take proportionately longer to execute.  If necessary we could add padding for statements that take much longer than average to execute.

I like the idea of padding.

I don't.  Its only purpose is the make the subsequent SHA-256 operation a more constant proportion of the total running time.  It also makes it more expensive.  This whole idea of adding overhead to make the system more secure might have some merit if it worked, and if our goal was only to build a slightly better bitcoin by harvesting as useful work a few percent of its PoW effort.  But it doesn't work, and I'd prefer to have the overhead rather than the useful work at the few percent level.

Quote
We would have to "empirically" determine which operations require padding and which not.

Yes, and average it over very different hardware.  What if an attacker were to run his FAA on an ASIC crafted for the purpose?  A faster-algorithm-in-the-hardware attack. In fact, this is exactly what has happened to bitcoin over the past few years.  For us, it is a nightmare.

Quote
Quote
Next note that SHA-256 is a serial algorithm.  We don't even need to allocate storage for the buffer; we just pipe it straight in.  Finally, note that it is a linear-time algorithm.  Any new algorithm computing the same function can be at best a constant times faster, otherwise finding collisions becomes trivial.  This is the basis for my claim that even the most powerful faster algorithm imaginable - an oracle that fills the buffer instantly - can achieve at best a linear speed-up.

Agreed.

It's a convincing argument.  It's not sound, though.  It took me a while to realise that.

What I have informally proven here, is that in a random oracle model in which the oracle is time-linear in the size of the input, the best an attacker can achieve is a linear speed-up.

Unfortunately it turns out that supra-linear speed-ups of SHA-256 and indeed all sequential hash algorithms are possible in some circumstances.  Let s be a security parameter.  Let S be a fixed string of length s.  Let c be a constant.  Let Ci be an arbitrary sequence of strings of length c.  Let S.Ci denote the concatentation of S and Ci and let Ci.S be construed accordingly. Then in the time-linear random-oracle model, the time to compute both sequences Oracle(S.Ci) and Oracle(Ci.S) are, trivially, both O(s).  However SHA-256(S.Ci) is trivially O(1).  All you do reuse the saved state of the SHA-256 algorithm for the constant part of the string.  I think SHA-256(Ci.S) is likely to be O(s), but I can't prove it.  Can you?

And this is serious, because our PoW protocol is precisely to compute sequences of SHA-256 where the input string has parts which can be manipulated by an adversary, and other parts which are constant.

This should be an object lesson in why people should be very, very, skeptical about claims of security proofs.  

Quote
Would it help to use the previous block to "seed" the buffer? It would add extra security in the sense that an attacker has only the time between two blocks to handcraft a PoW function which fits his "needs".

This is encryption, and if we're talking about 10ms segments, it helps not one iota, though it does add some overhead he can't avoid.  He doesn't have a limited time to handcraft his function.  He doesn't have to handcraft anything; he can use any innocent program such as might have been written by some other honest buyer.  All he has to do is find a reasonably tight loop which the program stays in for longer than 10ms, and runs the program "honestly" to reach that point.

Next he runs a 10ms segment "honestly" to fill the buffer.  Then he can screw around all he likes with any part of the state not read during the loop, and compute hash after hash after hash using the same buffer until he finds one that works.  The state of the crypto at the start of the segment is just another part of the program state read during the loop.  As long as he doesn't touch it, then the buffer will be valid.

The attacker has his oracle.  The buffer is filled up instantly because it is the same buffer he used before.

In fact the attacker can do even better than this.  He doesn't need to run the program "honestly" to reach his start point.  He can just initialise the read variables, including the crypto state, with plausible values.  If he keeps a copy of the unencrypted buffer, he could even screw around with the crypto state, reencrypting the buffer as necessary.  Think of the unread state, excluding the crypto state as analogous to bitcoin's "Nonce" then the crypto state could be "ExtraNonce", there to be used if the "Nonce" is too small, with just a little extra overhead.

So we see that the FAA is like a virus that exploits the very immune system which is intended to fight it.

Of course if it's the entire program, not just a 10ms segment, that is the PoW function, then yes, I agree that it would be difficult for an attacker to craft his program, especially if the crypto is seeded by the previous block, but then we're back to limiting the program time, which I don't want to do.  Additionally "difficult"/="impossible".

At this point it is my opinion that user supplied PoW is dead in the water and we need to find another way to secure the blockchain.
Cryptorials
Hero Member
*****
Offline Offline

Activity: 655


Cryptorials.io


View Profile
February 24, 2016, 09:56:31 AM
 #25

At this point it is my opinion that user supplied PoW is dead in the water and we need to find another way to secure the blockchain.

The entire point in this coin is user supplied PoW. You're saying that at this point you want to randomly make up a new coin to create?

Evil-Knievel
Legendary
*
Offline Offline

Activity: 1106



View Profile
February 24, 2016, 10:10:21 AM
 #26

This message was too old and has been purged
Dazza
Jr. Member
*
Offline Offline

Activity: 56


View Profile
February 24, 2016, 10:26:29 AM
 #27

Next he runs a 10ms segment "honestly" to fill the buffer.  Then he can screw around all he likes with any part of the state not read during the loop, and compute hash after hash after hash using the same buffer until he finds one that works.  The state of the crypto at the start of the segment is just another part of the program state read during the loop.  As long as he doesn't touch it, then the buffer will be valid.

This is probably flogging a dead horse, but it just occurred to me that if the program state is stored in a Merkel tree, we could use StateMerkelRoot as an encryption key, which would not only change every instruction, but would force the attacker to reencrypt the entire buffer every time he tweaks the state.
Dazza
Jr. Member
*
Offline Offline

Activity: 56


View Profile
February 24, 2016, 10:36:10 AM
 #28

The entire point in this coin is user supplied PoW. You're saying that at this point you want to randomly make up a new coin to create?

I don't necessarily want to.  At this point I think we may have to, unless you by chance have any ideas as to how we slay the FAA dragon?

At this point I think my vision of the project is that our goal is to build a distributed market for computer resources, which uses secure protocols to guarantee that sellers get paid, buyers get correct results, and nobody gets his computer hacked.  I am, in principle, agnostic about the technology used to achieve this, though I believe that a new cryptocurrency will be a centrepiece.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1106



View Profile
February 24, 2016, 10:53:13 AM
 #29

This message was too old and has been purged
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1106



View Profile
February 24, 2016, 12:13:45 PM
 #30

This message was too old and has been purged
Videodrome
Hero Member
*****
Offline Offline

Activity: 658


Free Julian Assange


View Profile
February 24, 2016, 01:35:52 PM
 #31

In my opinion EK should make one, and only one rock-solid unbreakable commitment at this point.  And that is that anybody who has cotributed BTC so far can have their money back right now, no questions asked, and that this offer will remain in place until we can come up with a clear, coherent statement of what it is we are proposing to do.

Well, first my short opinion on this.
I find it really hard to plan mid to long term when people can request charge backs of their "donations" arbitrarily.
All contributions should be final, non-refundable and at the disposition of the coin's developers.
Donating should always be coherent with trust in the coin's future and in the development in general.

However, in this case I understand that it would be fair to allow a withdrawal from the project for a limited time.
I have therefore created a charge back function which can be found here: http://elastic.pro/chargeback.html.
Until February, Friday 26th 2016 3:00pm GMT[/url] people can just request their donation back ... no questions asked.
I have chosen this time because we have to start planning mid-term now. And only if we have the BTC "for sure" we can do that.

Here is how you operate the charge back function, exemplarily, using Electrum:



REGARDING THE TERMS

I suggest letting the terms of the crowdfunding process untouched.
The moment the charge back function closes, block 400000 will already have passed: so a later re-entrance will inevitably lead to less ELC/BTC.
I think this is required to both avoid strategic withdrawals and a disadvantage of current supporters who maybe made their decision based upon the assumption that the reward will drop from block 400000 on-wards.




Thank you for your honesty and consistency, my investment will not be withdrawn.

since you've taken action, this project has gained value, not the reverse.

i'm not a coder,so my help in this initial step is ZERO, but i hope in the near future to be able to help in marketing.

Dazza
Jr. Member
*
Offline Offline

Activity: 56


View Profile
February 24, 2016, 03:04:41 PM
 #32

i'm not a coder,so my help in this initial step is ZERO, but i hope in the near future to be able to help in marketing.

Briefly, because I've got a real-world job to do...

There are other ways people can contribute.  For example, at some point we're going to need alpha and beta testers.
Videodrome
Hero Member
*****
Offline Offline

Activity: 658


Free Julian Assange


View Profile
February 24, 2016, 03:08:32 PM
 #33

i'm not a coder,so my help in this initial step is ZERO, but i hope in the near future to be able to help in marketing.

Briefly, because I've got a real-world job to do...

There are other ways people can contribute.  For example, at some point we're going to need alpha and beta testers.

I'm a good linux tester!

not a pro but an exp user.
xxxgoodgirls
Legendary
*
Offline Offline

Activity: 1064



View Profile
February 24, 2016, 03:13:47 PM
 #34

i'm not a coder,so my help in this initial step is ZERO, but i hope in the near future to be able to help in marketing.

Briefly, because I've got a real-world job to do...

There are other ways people can contribute.  For example, at some point we're going to need alpha and beta testers.

Are you gonna join the team?

.
   █████▄▄▄▄
   ████████████▄▄▄            ▀██████
   ███ ▀▀▀▀█████████▄          ▀█████
   ███         ▀▀▀█████▄         ▀███
   ███              ▀▀████▄▄███    ▀▀
   ███                ▀███████▀
   ███                    █████
   ███     ███▄         ▄███████
   ▐██▌     ▀███▄     ▄███▀  ███
   ▐███       ▀███▄▄ ███▀     ███
    ███▌        ▀████        ▐██▌
     ███         ████         ███
      ███      ▄█████▄       ▐██
       ███   ▄████▀ ▀███▄     ▐██
        ███▄████▀     ▀███▄   ███
         █████▀         ▀███▄████
          ██▀             ▀█████▌
                            ▀███▌
  ██████                      ▀▀
  ▀▀▀███
     ███
█         █   ███
 █        ███  ███  █
███       ███   █  ███
███   █   ███   █  ███
███  ███   █       ███
███  ███   █       ███
 █   ███            █
 █    █             █
█         █   ███
 █        ███  ███  █
███       ███   █  ███
███   █   ███   █  ███
███  ███   █       ███
███  ███   █       ███
 █   ███            █
 █    █             █
             JOIN US             
TELEGRAM TWITTER FACEBOOK
LINKEDIN WHITEPAPER
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1106



View Profile
February 24, 2016, 04:07:26 PM
 #35

This message was too old and has been purged
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1106



View Profile
February 24, 2016, 04:15:22 PM
 #36

This message was too old and has been purged
poornamelessme
Hero Member
*****
Offline Offline

Activity: 644



View Profile
February 24, 2016, 04:37:32 PM
 #37


In my opinion EK should make one, and only one rock-solid unbreakable commitment at this point.  And that is that anybody who has cotributed BTC so far can have their money back right now, no questions asked, and that this offer will remain in place until we can come up with a clear, coherent statement of what it is we are proposing to do.

Other than that, everything should be up for discussion, including the terms of the crowdfunding.


I know I suggested this to EK, but will mention it here too ... I think the entire ICO should start over from scratch.

Just make this a pre-announcement. Keep the ICO on hold until the whitepaper is finished.

Then set things up proper ... escrow, lawyer (ideally) involved, do some marketing before the ICO, announce which coders are involved with the project, every team member, backgrounds and so on.

I mentioned to EK how Lisk's ICO is doing, for instance (over 750 btc in like 2 days). Look at how they set theirs up. I'm not saying Elastic would do as well, but it could do a lot better than it has been as far as money taken in.

cyberhacker
Legendary
*
Offline Offline

Activity: 1162



View Profile WWW
February 24, 2016, 04:56:57 PM
 #38

since some one mentioned LISK here,

I have to say LISK is so fishy, I'd rather throw money here, not go to Crypti 2.0. they want to screw ppl twice?

I really don't see anything special in LISK, and I don't know who exactly put money in ICO. maybe those ppl behind the whole scheme.



BTC12.COM 
Elastic.pw Elastic Network: The Decentralized Supercomputer 
ANNOUNCEMENT THREAD | JOIN THE SLACK
Cryptorials
Hero Member
*****
Offline Offline

Activity: 655


Cryptorials.io


View Profile
February 24, 2016, 05:02:46 PM
 #39

I know I suggested this to EK, but will mention it here too ... I think the entire ICO should start over from scratch.

Just make this a pre-announcement. Keep the ICO on hold until the whitepaper is finished.

Then set things up proper ... escrow, lawyer (ideally) involved, do some marketing before the ICO, announce which coders are involved with the project, every team member, backgrounds and so on.

I mentioned to EK how Lisk's ICO is doing, for instance (over 750 btc in like 2 days). Look at how they set theirs up. I'm not saying Elastic would do as well, but it could do a lot better than it has been as far as money taken in.

Personally I don't think that's necessary, and I think its a bit early to have much idea how well this ICO is going to do - you aren't going to get 100s of btc per day in a sale that lasts for 6 months or something.

poornamelessme
Hero Member
*****
Offline Offline

Activity: 644



View Profile
February 24, 2016, 05:04:17 PM
 #40

since some one mentioned LISK here,

I have to say LISK is so fishy, I'd rather throw money here, not go to Crypti 2.0. they want to screw ppl twice?

I really don't see anything special in LISK, and I don't know who exactly put money in ICO. maybe those ppl behind the whole scheme.




I didn't mean my post to imply people should invest into Lisk. I meant Elastic should look at how they set their ICO up, use it as a template (or just get ideas) on how to set this one up. It's very professional, and has taken in a ton of money, really quickly.

I also doubt the founders had 750+ btc sitting around to invest in their own coin... I expect it's mostly people who missed the boat on ETH, or those who made a lot of profit from it, investing over there.

Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 »  All
  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!