Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 300. (Read 450524 times)

Today I have finished the PoW transmission rate. This one is pretty tricky.

First, we have the blockchain which is built using proof-of-stake. This one is controlled by our exponentially-rising-target function which guarantees that a block is found after a maximum and reasonable upper  bound of x minutes.

But then we also have the proof-of-work submissions that pay out the workers (not the miners). Those are regular transactions, but we want to limit their rate as well. We want to have no scalability issues even if millions of people start working on Elastic at the same time. For this, I have a second target value which is somewhat adjusted using empirical block data from the last 12 blocks.

It functions like a sliding window and it readjusts the proof-of-work target value based on the number of proof-of-work packages inside the last 12 blocks. The target is (still changeable) 120 proof-of-work transactions in the last 12 blocks.

Here the retargetting itself:
https://github.com/OrdinaryDude/elastic-reference-client/blob/e398082bc3850b0318d5cf4f511b8353edd6b2c8/src/java/nxt/WorkLogicManager.java#L35-L94

Here the entire commit with all related changes:
https://github.com/OrdinaryDude/elastic-reference-client/commit/e398082bc3850b0318d5cf4f511b8353edd6b2c8

The problem is now, that the retargetting algorithm does not immediately react to high bursts in proof-of-work packages. So a DOS attacker might first keep the target value reasonably high (difficulty low), and then flood the blockchain with thousands of proof-of-work transactions within the ~1 min time span until the next block is found and the per-block readjustment of the difficulty kicks in. Any ideas are welcome here, as well as comments for the retarget function.

To clarify once again:
1.) we have the standard exponential targetting to adjust the rate at which the blockchain grows
2.) we have the DGW style sliding window retargetting the proof-of-work transaction difficulty to ensure that we have ~120 proof-of-work transaction in each sliding window of 12 blocks.

Back to the old discussion here: private keys. There are two types of private keys: uncompressed, which begin with a 5; and compressed, which begin with a K or L.

I know a certain app JAXX is telling me that the private key of certain bitcoin address is beginning with a letter K or sometimes with letter L.   What does this mean for Elastic import or sweep function to import? Will be both compressed or uncompressed be supported?

Noted - thanks 

IPO end at block 425920

Does the final phase start or end at block 425920?

Thanks

You have a point in terms of funds which will not be accumulated due to pre-trading. I also consider the resources (espcially time) you need just to make a pre-trade possible and keep all running. I'm not sure if this will give additional value to the project.

Long ICO ever but it's worth the wait.

Thank you very much sir!

Between my 1BTC for 8000 XEL selling proposal is still valid, some guy contacted me but apparently they did not ultimate the trade or at least they have not yet responded me back, so, get your XEL at best rate on the market ever please!

Sure,

I first went to blockchain.info and took a look at the raw script which was:

OP_FALSE 304402202d10cc1c26aad9c31e7e1e13e58e2fb765be5d244891f925eee16392815d7d9e022031f 91dc0a2719e771d44dd1783dc999d84e41614c576816f6e27bd4d2d5e6c4701 3045022100c080f855026a3cec985e46d68302be8f1211432a1e2ecd8326aecdeabeceeda302204 028be51d927fb9eef419e9f3c57ae4ce8d8ff37ca172d0af4d63762f0012c2801 5221028e3ff9878134a6248483c7e6b4a9885b47185034f035b439098f71e7fc2f508c2102d1ae2 18b3d2d0009dd5f12eeae8195055913d413e92b823737992c1c136c145321033fcfadccd1040576 e86105fd70f71a89426b813bea55d7155c4e91773d5da67653ae

The red part is the input script, most of the time starting with a 5.

In a next step I downloaded this piece of software:
https://bitbucket.org/albrow/bitcoin-script-encoder-decoder

And just did a:

ruby script.rb decode 5221028e3ff9878134a6248483c7e6b4a9885b47185034f035b439098f71e7fc2f508c2102d1ae2 18b3d2d0009dd5f12eeae8195055913d413e92b823737992c1c136c145321033fcfadccd1040576 e86105fd70f71a89426b813bea55d7155c4e91773d5da67653ae

The result was:
OP_2 21 028e3ff9878134a6248483c7e6b4a9885b47185034f035b439098f71e7fc2f508c 21 02d1ae218b3d2d0009dd5f12eeae8195055913d413e92b823737992c1c136c1453 21 033fcfadccd1040576e86105fd70f71a89426b813bea55d7155c4e91773d5da676 OP_3 OP_CHECKMULTISIG

... and it contains your three public keys.

final donation phase, block 425920, espected 10/august aprox

The bauty of thos project is that you don't invest, you donate.

I forgot I invested in this project, any updates? Loved the initial vision.

Yeah it matches! Thank you so much!
Mind to share how did you get the inputs? I will try to check the other two transactions as well.

I wouldn't mind that, as a guy who donated, because if there is a lower price to buy on exchange than it is to donate to the project, it means less XEL are issued and more are distributed to people who have already donated, the problem is that this would lower the funds for the project and its probably best for the project to collect them to pay for additional development. With the price of BTC going up, the lower price of XEL if its issued early is a real possibility and right now XEL is sort of pegged to BTC, if issued early that would probably mess with that to some degree. Personally I'm against the early release.

... yes, and all three multisig wallets seem to be different 

The last one 8cd58d9367016007c03acbd51feeb61453feea624dd333034df8af32ff3eccee
has the input script


So you will need two of three private keys that belong to these public keys:

028e3ff9878134a6248483c7e6b4a9885b47185034f035b439098f71e7fc2f508c
02d1ae218b3d2d0009dd5f12eeae8195055913d413e92b823737992c1c136c1453
033fcfadccd1040576e86105fd70f71a89426b813bea55d7155c4e91773d5da676

Does that make sense or am I totally wrong here?

I just figured out I sent the donations from a multisig wallet, might it be the cause of the mismatch?

agree, i would like to wait until everything works as intended.


exchanges add coins by themself, they dont ask for permission. 

279e3b67779f4afbd42964ab8ded0ea519440994216ce45affbd3d7d10138e62
058ea25fd0853776508ad73fd284a9e30fd0ad47ff8a2245822b15ea530503c7
8cd58d9367016007c03acbd51feeb61453feea624dd333034df8af32ff3eccee

Thank you sir!

The only problem I see (if it even is a problem) is that soon after the basic wallet is released and people get their XEL they will start pushing for an exchange.

If it is added to an exchange it will probably get dumped on. For some reason I cannot understand there are always people willing to dump even at a loss.
Then it will become a vehicle for speculation like all other basic altcoin clones.

I'm not sure what effect it will have on its reputation. It might not even matter after the full featured platform is released. Just be aware of the possibility.

Are you planning on adding it to an exchange before the full platform is released?

If you could share your txid with us, we could take a look ;-)