Lannister (OP)
Full Member
Offline
Activity: 140
Merit: 500
I'm blocking all private messages. Use Bitmessage!
|
|
September 23, 2016, 09:05:24 AM |
|
Questions?
I'm sorry for the absence. My schedule has been swamped this year and things have been a little hectic lately with little room for spending time at the computer. I do have a question indeed: could you share your BTC address so I can throw a few thousand pounds worth of BTC your way for what you have so far disclosed? That's what I've got for now in my mobile wallet, plenty more to come after I finished downloading the blockchain. Considering your knowledge I hope you would be able to stick around and shed some more light on the flawed parts of the project.Your help is much appreciated.
|
No, I will not disclose my real name on the Internet. The very simple reason I’m anonymous is so that I can talk freely about a free web. One mistake people often make is having the faulty assumption that knowing my real name or my association with a respected person, group or organization might get them to trust me more. In fact, I have no authority here. Elastic Project is a loosely associated group of developers which constantly changes over time. If you prefer projects with a more centralized structure, then please move on. Specifically, I kindly ask you to refrain from any messages that try to convince me of the contrary. My time is too valuable to be wasted with the same discussion again and again.
|
|
|
|
|
You get merit points when someone likes your post enough to give you some. And for every 2 merit points you receive, you can send 1 merit point to someone else!
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
e1ghtSpace
Legendary
Offline
Activity: 1526
Merit: 1001
Crypto since 2014
|
|
September 23, 2016, 11:16:56 AM |
|
http://www.elastic.pro/The website seems to be down... For me it "took too long to respond." Is anyone else having trouble accessing the site or is it just me?
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
September 23, 2016, 11:23:22 AM Last edit: September 23, 2016, 12:46:53 PM by Evil-Knievel |
|
Right now, testnet tokens are just "free" anyway, you can basically mine proof shares without actually doing the job's work... so if I need some coins I'll just "take" them from the network! (But that is another bug, for another day...) So I guess that today is as good a day as any.... Let's look at an (only slightly more) interesting and fun bug, which we'll call "HMC bug #6" but which is more generally known as "basic work stealing." (Note that XEL is not the first design to encounter this problem!) [...] I'm impressed!!! Thank you so much for sharing your thoughts with us! I have implemented a fix in the development branch! The most interesting part happens here:https://github.com/OrdinaryDude/elastic-core/blob/development/src/java/nxt/Attachment.java#L274-L4291. Miners have to provide a <=32byte long "seed" called the "multiplicator" instead of the direct integer arguments. 2. Then a random number stream is derived from the public key of the sender, the workId and the 32 byte long seed by hashing those values using sha256. 3. This random number stream is then used to obtain exactly 12 random integers which are then passed to the ElasticPL program. Hijacking other people's proof of work therefore should be no longer possible. All that comes at the cost of an additional effort to compute the sha256 hashes for the random number inputs at the miner's side. THANKS FOR SHARING!!! I HOPE TO GET MORE HINTS ON HOW TO "DECONSTRUCT" XEL SOON ;-)!!EDIT: Miner has also been updated on the development branch!
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
September 23, 2016, 01:00:08 PM Last edit: September 23, 2016, 04:40:06 PM by Evil-Knievel |
|
Currently, most of HunterMinerCrafter's bugs are fixed in this version! Cleaning out the remaining few parts.
It does seem improved, but still some related problems. For example: still causes a cast exception. (There are other cases...) Fixed this (and that m[(1>0)]=1)! Thanks! EDIT: Elliptic curve point operations now added to ElasticPL for SECP256k1 for both compressed and uncompressed representations. Example script: input 12; m[0] = 0; m[1] = 0; m[2] = 0; m[3] = 0; m[4] = 0; m[5] = 0; m[6] = 0; m[7] = 1; m[10] = 0; m[11] = 0; m[12] = 0; m[13] = 0; m[14] = 0; m[15] = 0; m[16] = 0; m[17] = 1; m[999] = 4; SECP256K1PrivToPub 0 true; SECP256K1PrivToPub 10 true; SECP256K1PointAdd 0 true 10 true true; SECP256K1PointScalarMult 10 true 999 4 true; verify (1==1);
Specification: SECP256K1PrivToPub <startinteger_state_of_32byte_privkey INT> <compressed_output BOOL> SECP256K1PointAdd <startinteger_state_pt1 INT> <compressed_pt1 BOOL> <startinteger_state_pt2 INT> <compressed_pt_2 BOOL> SECP256K1PointSub <startinteger_state_pt1 INT> <compressed_pt1 BOOL> <startinteger_state_pt2 INT> <compressed_pt_2 BOOL> SECP256K1PointScalarMult <startinteger_state_pt1 INT> <compressed_pt1 BOOL> <startinteger_state_scalar INT> <scalar_bytes INT><compressed_output BOOL> -- all outputs are written to the memory beginning at startinteger_state
Testoutput of example script: Elastic Programming Language Interpreter Version 0.1: Reading from file ec.spl . . . [!] Worst case execution time: 12017 [!] Random integers specified: 12 m[0]: 46531711 m[1]: -1807618691 m[2]: 1831880000 m[3]: 1855307900 m[4]: -665028722 m[5]: 1267527484 m[6]: -1481921527 m[7]: -1185124194 m[8]: -452984832 m[9]: 319628733 m[10]: 48534491 m[11]: -239006336 m[12]: -212328887 m[13]: 76745492 m[14]: 80505875 m[15]: -1878073227 m[16]: -2072708460 m[17]: -1410808627 m[18]: 318767104 m[999]: 4 [!] Bounty requirement met: true
Converting the integers to hex, you will find out that the two calculated EC points are correct!!! 2*G = 02C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5 4*G = 02E493DBF1C10D80F3581E4904930B1404CC6C13900EE0758474FA94ABE8C4CD13
|
|
|
|
|
beyinsi
|
|
September 23, 2016, 10:20:13 PM |
|
ek, when will be ready elastic? can u tell us a roadmap,
|
|
|
|
atomicgroup
|
|
September 24, 2016, 04:25:52 AM |
|
hi, i have partecipate at the ICO but i dont receive my XEL... can you help me?
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
September 24, 2016, 04:32:16 AM |
|
hi, i have partecipate at the ICO but i dont receive my XEL... can you help me?
We are still in the testnet phase.
|
|
|
|
yosir
|
|
September 24, 2016, 08:41:16 AM |
|
Hi,
Great job guys. I see dedication and skill that can't be found in most of projects. If I may ask, is there a way to buy more XEL now, after ICO? Is there some kind of mechanism (not platform but a safe process) for sell/buy between participants of ICO?
Thanks, Yossi
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
September 24, 2016, 08:53:13 AM Last edit: September 24, 2016, 12:24:25 PM by Evil-Knievel |
|
EDIT: Do we want elliptic curve arithmetics supported natively?
That would be interesting, but IMO what would be very interesting would be to include native "FHE" (homomorphic) operations. I could imagine many users would be willing to trade performance of their job evaluations for protection of information related to their work algorithm. I have thought about FHE operations, but do they really need a native support? Or is the support already there implicitly because you can apply the regular *, /, +, -, % operations on "encrypted values"? If you think of a Palier cryptosystem, and let D() be the decryption routine and E() the encryption routines. Now let's assume someone wants to calculate something arbitrary, to keep it simple let's say (x * y) % n. Wouldn't it be sufficient, for a work author, to provide E(x) and E(y), and let the program calculate (E(x)*E(y) % n^2) using it's native methods since D(E(x)*E(y) % n^2) = (x + y) % n? Also, I think in the first place it might become complicated using "encrypted values" in the verify routine. EDIT: Following elliptic curves are now supported natively in ElasticPL:("secp192k1","secp192r1","secp224k1","secp224r1","secp256k1","secp256r1","secp384r1","prime192v1","prime192v2","prime192v3","prime256v1")
|
|
|
|
HunterMinerCrafter
|
|
September 24, 2016, 12:27:09 PM |
|
Edit: I think I understand now....you are saying that the hash wont get propegated so unless the inputs are unique to me anyone can steal it....that sux :-)
Right, there is a subtle variant of Sybil attack here. Cathy is racing Bob to propagate their work certificates. Even if we told the story with 2 users acting as single peer nodes (not Sybil) on acoustic couple or home broadband Cathy basically still has a 50/50 shot at stealing any given work solution that she sees. At that point it would likely just come down to network routing topology. With even a small out-resourcing (obv my story was over the top, by today's standards) Cathy could pretty much trivially ruin Bob's day the vast majority of the time.
|
|
|
|
HunterMinerCrafter
|
|
September 24, 2016, 12:28:13 PM |
|
Considering your knowledge I hope you would be able to stick around and shed some more light on the flawed parts of the project.Your help is much appreciated.
Thanks! I'll stick around until I run out of interesting and/or fun ways to (ab)use the network. If there's still a meaningfully "useful" network left when I'm done, maybe I'll even stick around longer.
|
|
|
|
HunterMinerCrafter
|
|
September 24, 2016, 12:29:19 PM |
|
P.S.
BTC address: 1EVnmWVjTWWEbHrWenoyJ3k7wroyAD1K1r
|
|
|
|
HunterMinerCrafter
|
|
September 24, 2016, 12:31:43 PM |
|
I'm impressed!!!
Thanks! 1. Miners have to provide a <=32byte long "seed" called the "multiplicator" instead of the direct integer arguments. 2. Then a random number stream is derived from the public key of the sender, the workId and the 32 byte long seed by hashing those values using sha256.
I think that including the workId (this is derived from the block hash wher the work is published iirc?) probably closes at least one other attack on my list. Prior to this change, a job publisher could also precompute PoW certificates for the work to return those funds to himself immediately after publishing... 3. This random number stream is then used to obtain exactly 12 random integers which are then passed to the ElasticPL program.
This does seem to prevent the basic work stealing problem. If you actually fill the entire memory space it would also mitigate (but not entirely prevent) another attack still on my list. THANKS FOR SHARING!!! I HOPE TO GET MORE HINTS ON HOW TO "DECONSTRUCT" XEL SOON ;-)!!
The laundry list is still growing. I'm finding a few new attacks each day, and with the weekend now here I'll have some time to *really* focus again.
|
|
|
|
HunterMinerCrafter
|
|
September 24, 2016, 12:32:50 PM |
|
Fixed this (and that m[(1>0)]=1)! Thanks!
I'll make another pass over the parser first thing and let you know if I find any of these remaining. Also fixed, the WCET tricking bug,
There is definitely at least one problem remaining in the RuntimeEstimator, but I'm still working out some details.
|
|
|
|
HunterMinerCrafter
|
|
September 24, 2016, 12:34:25 PM |
|
I have thought about FHE operations, but do they really need a native support? Or is the support already there implicitly because you can apply the regular *, /, +, -, % operations on "encrypted values"?
If you think of a Palier cryptosystem,
Paillier is only partial homomorphism. Also, I think in the first place it might become complicated using "encrypted values" in the verify routine.
This is no problem for FHE, there are several approaches. This is commonly applied with "searchable encryption" schemes. (Basically publisher gives an index of acceptable values and a trapdoor to check if a value is in the index.) Other option is to use bit circuits instead of word-width operations. Then you reduce size of the output value until it crosses a probability threshold. (This approach will produce some error (more error the less you reduce size of output) so you might miss some solution or pay for some solution which is not actually valid.) Downside is that this makes for significantly larger programs. These are all forms of "conditional disclosure of secrets" schemes, there are many and they are well studied, particularly in the past 5-10 years. (Such "conditionals" are also possible with partial HE as in "cryptoleq" but they necessarily weaken security as they must do partial decryptions with obfuscation, so they necessarily reveal more than at most one bit of information.)
|
|
|
|
Lannister (OP)
Full Member
Offline
Activity: 140
Merit: 500
I'm blocking all private messages. Use Bitmessage!
|
|
September 24, 2016, 12:38:13 PM |
|
P.S.
BTC address: 1EVnmWVjTWWEbHrWenoyJ3k7wroyAD1K1r
I have just sent you 4 BTC. At this point I have to mention that you are solely responsible for ensuring that your federal income taxes are paid at the right time. https://blockchain.info/tx/d6694f56b875f517d7aa8c1c58a7ec42d0c7169ed94a5645b1f6f6bc82bf3de5
|
No, I will not disclose my real name on the Internet. The very simple reason I’m anonymous is so that I can talk freely about a free web. One mistake people often make is having the faulty assumption that knowing my real name or my association with a respected person, group or organization might get them to trust me more. In fact, I have no authority here. Elastic Project is a loosely associated group of developers which constantly changes over time. If you prefer projects with a more centralized structure, then please move on. Specifically, I kindly ask you to refrain from any messages that try to convince me of the contrary. My time is too valuable to be wasted with the same discussion again and again.
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
September 24, 2016, 12:56:36 PM |
|
I think that including the workId (this is derived from the block hash wher the work is published iirc?) probably closes at least one other attack on my list. Prior to this change, a job publisher could also precompute PoW certificates for the work to return those funds to himself immediately after publishing... Actually, the workId is derived from the transaction (not the block) in which it was published so I guess yes .. your attack would work. While not interesting for the PoW certificates (you can very well charge back using the work cancellation button) it might become interesting when precalculating bounties, submitting them prior to the closure of a work to get most of the bounty fund payout for one-self (remember, the fund is always distributed among all bounty submissions after the work has been closed). I am starting to fix that right away! This does seem to prevent the basic work stealing problem. If you actually fill the entire memory space it would also mitigate (but not entirely prevent) another attack still on my list.
Actually, I am right now filling the entire 12 integers of "possible input entropy" but not the entire memory space. If required to do so, we could go this way, even though this would increase the overhead noticably. Right now it's pretty handy to have large parts of the memory "nulled". I am really eager to hear about this attack The laundry list is still growing. I'm finding a few new attacks each day, and with the weekend now here I'll have some time to *really* focus again.
I hope (and I really believe) that with your help we can get rid of most (all?) these problems Also, I am really excited to hear about your next discoveries and start brainstorming about ways to conquer them. After all, you have my sincere appreciation for your help!!
|
|
|
|
unvoid
|
|
September 24, 2016, 01:54:16 PM |
|
New account info added to explorer.
Next I'll try to implement some charts.
|
BTC: 1CMgHWx4wkAaAy2FfeCyPdedUExmhGhfi5 XEL: XEL-HCM8-KB6E-YFLK-8BWMF
|
|
|
provenceday
Legendary
Offline
Activity: 1148
Merit: 1000
|
|
September 24, 2016, 01:58:27 PM |
|
Almost 100 pages before mainnet release.
|
|
|
|
|