[ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 251.

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

@trader19:

Quote

im pretty noobish but shouldnt there be diff POW hash posted instead of one character "f"?

This is our biggest to do yet. Since there was no work in the last 3 blocks, the difficulty got reset to the minimal-difficulty POW hash
which is 0000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff.

I will post a longer work now, you will see that this hash will quickly change again! But the resetting to the minimal difficulty hash is one major issue to be done.

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

Bounties are now displayed in the UI ;-) I will make is "hidden" on default not to look to "cluttered".
The "strange" outputs are fine, btw ;-) They are just for debugging the retargetting of the difficulty.

tomkat

hero member

Activity: 1022

Merit: 507

What is actually "Regular Bitcoin Signature" in redeem function?

trader19

legendary

Activity: 1232

Merit: 1001

Quote from: Evil-Knievel on September 19, 2016, 04:40:18 AM

hagie, starting with that now!

great, i have the same error. one more thing EK, i have bunch of strange lines on my logs.

Code:

Retargetting: Had POW 1 should be 30, scaling by factor 1.25
old diff was: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
new diff is : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Cleaning up unconfirmed tx, that got invalid ...
Retargetting: Had POW 1 should be 30, scaling by factor 1.25
old diff was: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
new diff is : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Cleaning up unconfirmed tx, that got invalid ...
Retargetting: Had POW 1 should be 30, scaling by factor 1.25
old diff was: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
new diff is : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Cleaning up unconfirmed tx, that got invalid ...
Retargetting: Had POW 1 should be 30, scaling by factor 1.25
old diff was: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
new diff is : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Cleaning up unconfirmed tx, that got invalid ...
Retargetting: Had POW 1 should be 30, scaling by factor 1.25
old diff was: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
new diff is : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Cleaning up unconfirmed tx, that got invalid ...
Retargetting: Had POW 1 should be 30, scaling by factor 1.25
old diff was: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
new diff is : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Cleaning up unconfirmed tx, that got invalid ...

im pretty noobish but shouldnt there be diff POW hash posted instead of one character "f"?

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

hagie, starting with that now!

hagie

hero member

Activity: 792

Merit: 501

Still can't register my account or create a work package :

Code:

Could not validate unsigned bytes returned by the server.

Regards

hagie

hero member

Activity: 792

Merit: 501

Quote from: Evil-Knievel on September 18, 2016, 06:06:32 PM

Quote

Just found another little bug that may cause nodes to be blacklisted. Working on it!

Fixed! Public nodes are now with version 0.3.4 on a hard fork! Update is mandatory!

The fix: We do not check if work is closed when verifying a cancellation request or a POW/Bounty. While it would be usually correct to do so, this may lead to network splits when some nodes already "know" that a work was closed, and others don't. In this case such a submission would be invalid for some, and valid for others, causing some blacklisting madness. Without this verification, it may not happen anymore. Of course, you can submit multiple work cancellation requests (even for long time ago closed works), and they are perfectly valid. They just have no effect at all. (This sub-optimal scheme was adopted by NXT in their distributed asset exchange, so it's peer tested)

Public Node updated !

https://elastic.cryptnodes.site/

regards

akhavr

full member

Activity: 235

Merit: 100

Quote from: unvoid on September 18, 2016, 06:58:14 AM

Please paste your address again once you'll properly compile and run 0.3.2

Built from correct git, still the same address - XEL-AAZZ-X7YL-94HK-6TBJB

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

Quote

Just found another little bug that may cause nodes to be blacklisted. Working on it!

Fixed! Public nodes are now with version 0.3.4 on a hard fork! Update is mandatory!

The fix: We do not check if work is closed when verifying a cancellation request or a POW/Bounty. While it would be usually correct to do so, this may lead to network splits when some nodes already "know" that a work was closed, and others don't. In this case such a submission would be invalid for some, and valid for others, causing some blacklisting madness. Without this verification, it may not happen anymore. Of course, you can submit multiple work cancellation requests (even for long time ago closed works), and they are perfectly valid. They just have no effect at all. (This sub-optimal scheme was adopted by NXT in their distributed asset exchange, so it's peer tested)

Bgjjj2016

sr. member

Activity: 448

Merit: 250

Ben2016

Quote from: Evil-Knievel on September 18, 2016, 04:14:05 PM

Quote from: crilleaz on September 18, 2016, 04:07:45 PM

Should I have saved the txid when donating?

Actually not! All you will need is your private key or some kind of backup of your wallet which would allow the extraction of your private key. And the txid should be somewhere in the outgoing transactions of your addresses visible on any block explorer out there ;-)

hi EK, I have my private key and the public key. Do I still need the tx number ? Thank you for your time.

crilleaz

full member

Activity: 236

Merit: 100

★ Always strive for the best ★

Quote from: Evil-Knievel on September 18, 2016, 04:14:05 PM

Quote from: crilleaz on September 18, 2016, 04:07:45 PM

Should I have saved the txid when donating?

Actually not! All you will need is your private key or some kind of backup of your wallet which would allow the extraction of your private key. And the txid should be somewhere in the outgoing transactions of your addresses visible on any block explorer out there ;-)

Ah thanks! I will filter through them

Edit: found the address, thanks!

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

Quote from: crilleaz on September 18, 2016, 04:07:45 PM

Should I have saved the txid when donating?

Actually not! All you will need is your private key or some kind of backup of your wallet which would allow the extraction of your private key. And the txid should be somewhere in the outgoing transactions of your addresses visible on any block explorer out there ;-)

crilleaz

full member

Activity: 236

Merit: 100

★ Always strive for the best ★

Quote from: Evil-Knievel on September 18, 2016, 04:06:27 PM

Quote from: crilleaz on September 18, 2016, 04:02:32 PM

Hi guys,

I have 'donated' some btc a while ago but I kinda lost track of it. I have the following problem; I can't find my XEL..

I did follow the instructions on the site, but I can't find the original instructions so I can follow them again in order to find my coins. Does anyone has those (screenshotted for example)?

Your txid should be somewhere in here: https://github.com/elastic-project/genesis-block/blob/master/genesis-block.json

Should I have saved the txid when donating?

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

Quote from: crilleaz on September 18, 2016, 04:02:32 PM

Hi guys,

I have 'donated' some btc a while ago but I kinda lost track of it. I have the following problem; I can't find my XEL..

I did follow the instructions on the site, but I can't find the original instructions so I can follow them again in order to find my coins. Does anyone has those (screenshotted for example)?

Your txid should be somewhere in here: https://github.com/elastic-project/genesis-block/blob/master/genesis-block.json

crilleaz

full member

Activity: 236

Merit: 100

★ Always strive for the best ★

Hi guys,

I have 'donated' some btc a while ago but I kinda lost track of it. I have the following problem; I can't find my XEL..

I did follow the instructions on the site, but I can't find the original instructions so I can follow them again in order to find my coins. Does anyone has those (screenshotted for example)?

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

But we really need to think about the POW difficulty scaling.

Maybe we should organize a contest or so! The current scheme (inspired by the Dark Gravity Wave) obviously "sucks".
When you look at the past blocks, we are *faaaaar* from having a steady #10 tx per block, its more kind of oscillating, even though a miner is working constantly without much fluctuation in its computation power.

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

make sure to get the lastest one-liner fix i just committed.

unvoid

hero member

Activity: 535

Merit: 500

Quote from: Evil-Knievel on September 18, 2016, 01:29:58 PM

Version bump -> 0.3.3

This update is not very critical, so nobody really has to update.

Sometimes, it might happen that peers get blacklisted because they have
1. sent a POW for a transaction meeting a specific block's target value but
2. the receiver side already was ahead of the chain (maybe because it just forged a new block but not yet broadcasted it) with a different difficulty, rendering the received POW invalid and causing the peer to be blacklisted

Typical symptom was something like this happening occasionally when mining on the local node (this means, some other node has blacklisted us).

Code:

2016-09-18 20:25:08 FINE: Peer 108.61.177.169 version 0.3.2 returned error: {"error":"nxt.NxtException$NotValidException: Peer sends invalid transactions: [nxt.NxtException$NotValidException: Proof of work is invalid: does not meet target]"}, request was: {"protocol":1,"requestType":"processTransactions","transactions":[{"senderPublicKey":"d9d5c57971eefb085e3abaf7a5a4a6cdb8185f30105583cdb09ad8f61886ec65","attachment":{"input":[1665498805,-467634391,-1035598394],"version.PiggybackedProofOfWork":1,"id":"7680446930260947479"},"subtype":2,"amountNQT":0,"signature":"d536bc11494fad4bdbfd1477463ce3bd9361ba336591af792fb3ad291b6d9e0acd55e6fa302fbb7af798f6e0b32ddb081b38a7429393793e802d0e7d0f733d3c","feeNQT":0,"ecBlockHeight":3945,"type":3,"deadline":3,"version":1,"timestamp":88928708,"ecBlockId":"17321588210217598091"}]}, disconnecting

The fix was to introduce a soft_unblock. Basically, we do not block peers that send POW which are invalid but were valid in the last 5 blocks. For this we have added a second Exception type. Besides the regular "NotValidException" (which causes a peer to be blacklisted) we now have the LostValidityException. If the lost validity happened not later than 5 blocks ago, there will be no blacklisting, the tx will just be dropped silently.

Fixes:
https://github.com/OrdinaryDude/elastic-core/commit/6e836ef42701ba799715bb16d55f00a51a87048f (The fix)
https://github.com/OrdinaryDude/elastic-core/commit/4da2959b90e1ef6fab4adf598c8345a357d4890e (Added LRU cache, and fixed little bug)

Nice and clean. Give me few minutes to update node and explorer.

Thanks!

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

Version bump -> 0.3.3

This update is not very critical, so nobody really has to update.

Sometimes, it might happen that peers get blacklisted because they have
1. sent a POW for a transaction meeting a specific block's target value but
2. the receiver side already was ahead of the chain (maybe because it just forged a new block but not yet broadcasted it) with a different difficulty, rendering the received POW invalid and causing the peer to be blacklisted

Typical symptom was something like this happening occasionally when mining on the local node (this means, some other node has blacklisted us).

Code:

2016-09-18 20:25:08 FINE: Peer 108.61.177.169 version 0.3.2 returned error: {"error":"nxt.NxtException$NotValidException: Peer sends invalid transactions: [nxt.NxtException$NotValidException: Proof of work is invalid: does not meet target]"}, request was: {"protocol":1,"requestType":"processTransactions","transactions":[{"senderPublicKey":"d9d5c57971eefb085e3abaf7a5a4a6cdb8185f30105583cdb09ad8f61886ec65","attachment":{"input":[1665498805,-467634391,-1035598394],"version.PiggybackedProofOfWork":1,"id":"7680446930260947479"},"subtype":2,"amountNQT":0,"signature":"d536bc11494fad4bdbfd1477463ce3bd9361ba336591af792fb3ad291b6d9e0acd55e6fa302fbb7af798f6e0b32ddb081b38a7429393793e802d0e7d0f733d3c","feeNQT":0,"ecBlockHeight":3945,"type":3,"deadline":3,"version":1,"timestamp":88928708,"ecBlockId":"17321588210217598091"}]}, disconnecting

The fix was to introduce a soft_unblock. Basically, we do not block peers that send POW which are invalid but were valid in the last 5 blocks. For this we have added a second Exception type. Besides the regular "NotValidException" (which causes a peer to be blacklisted) we now have the LostValidityException. If the lost validity happened not later than 5 blocks ago, there will be no blacklisting, the tx will just be dropped silently.

Fixes:
https://github.com/OrdinaryDude/elastic-core/commit/6e836ef42701ba799715bb16d55f00a51a87048f (The fix)
https://github.com/OrdinaryDude/elastic-core/commit/4da2959b90e1ef6fab4adf598c8345a357d4890e (Added LRU cache, and fixed little bug)

unvoid

hero member

Activity: 535

Merit: 500

I wrote app that sends 1 XEL every one minute to last block finder. Hope this will be dummy transactions for blockchain to test it more (and blockchain explorer, we need dummy transactions to test it). So we have at least one transaction every minute.

@ImI for this purpose please 1M XEL @ XEL-7UTR-VYZY-ZUZZ-DTJJ5

Thanks!

http://elasticexplorer.org

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