Bitcoin Forum
October 18, 2019, 07:59:21 AM *
News: 10th anniversary art contest
 
   Home   Help Search Login Register More  
Pages: « 1 ... 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 [251] 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 ... 346 »
  Print  
Author Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer  (Read 449747 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.
coralreefer
Sr. Member
****
Offline Offline

Activity: 465
Merit: 260


View Profile
April 11, 2017, 09:58:48 PM
 #5001

Is queuing the right way to go at all?

I don't really see any way around it, but maybe some other bright minds around here can come up with a solution.

But the bottom line is we can easily have complex jobs that take considerable time to solve, and each submission would need to be validated.  For example, if I create a job that takes 0.1 sec to solve, and I dump 1000 submissions onto a SN, that node would be tied up for 2 minutes before it could do anything else.  And this will take place while people are dumping hundreds if not thousands of legitimate POW submissions on the SN.

I still don't know of a good solution...I still wish we didn't have POW in xel and just focused on bounties.  I know you'll say we need the POW logic ;-)  I'm just not convinced, and I feel like it just complicates the validation / targetting / volume issues.
1571385561
Hero Member
*
Offline Offline

Posts: 1571385561

View Profile Personal Message (Offline)

Ignore
1571385561
Reply with quote  #2

1571385561
Report to moderator
1571385561
Hero Member
*
Offline Offline

Posts: 1571385561

View Profile Personal Message (Offline)

Ignore
1571385561
Reply with quote  #2

1571385561
Report to moderator
1571385561
Hero Member
*
Offline Offline

Posts: 1571385561

View Profile Personal Message (Offline)

Ignore
1571385561
Reply with quote  #2

1571385561
Report to moderator
The Bitcoin software, network, and concept is called "Bitcoin" with a capitalized "B". Bitcoin currency units are called "bitcoins" with a lowercase "b" -- this is often abbreviated BTC.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1571385561
Hero Member
*
Offline Offline

Posts: 1571385561

View Profile Personal Message (Offline)

Ignore
1571385561
Reply with quote  #2

1571385561
Report to moderator
1571385561
Hero Member
*
Offline Offline

Posts: 1571385561

View Profile Personal Message (Offline)

Ignore
1571385561
Reply with quote  #2

1571385561
Report to moderator
by rallier
Legendary
*
Offline Offline

Activity: 1414
Merit: 1278


App Security Engineer, Cryptocurrency Enthusiast


View Profile WWW
April 12, 2017, 06:00:54 AM
 #5002

@EK: We can block time reduced to 30 sec for testing purposes. we never see what happens on 30k blocks
btw, pls import my last changes to repos
reduce block time for test is a good advice Grin

Dont listen to him. Increase block time to 2 minutes and put it on mainnet, u dont even need to test it. 2 min is ideal if u seek a trade-off between security and transaction propagation time. Reducing the block time will lead to the possibility of massive microtx spam. Tx fee is ridiculously low atm making spam attacks cheaper than ever before.
I said for testing purposes. You don't need to explain block time effects  Wink

To hire a Security Engineer, contact me.
by rallier
Legendary
*
Offline Offline

Activity: 1414
Merit: 1278


App Security Engineer, Cryptocurrency Enthusiast


View Profile WWW
April 12, 2017, 06:03:41 AM
 #5003

@EK:
I created Elastic-Coin github organization. my suggestion we can work repos on this organization. I invited you with admin privileges.
https://github.com/elastic-coin

We can add to more people and we can share to jobs .
If you accept invite, you should start push to elastic-coin repo. We will update all links to this organization url.
I will use release tags from your commits & i will update docker side @github.

@ek what do you think?

To hire a Security Engineer, contact me.
tomkat
Hero Member
*****
Offline Offline

Activity: 1022
Merit: 507


View Profile
April 12, 2017, 06:56:29 AM
 #5004

Is queuing the right way to go at all?

I don't really see any way around it, but maybe some other bright minds around here can come up with a solution.

But the bottom line is we can easily have complex jobs that take considerable time to solve, and each submission would need to be validated.  For example, if I create a job that takes 0.1 sec to solve, and I dump 1000 submissions onto a SN, that node would be tied up for 2 minutes before it could do anything else.  And this will take place while people are dumping hundreds if not thousands of legitimate POW submissions on the SN.

I still don't know of a good solution...I still wish we didn't have POW in xel and just focused on bounties.  I know you'll say we need the POW logic ;-)  I'm just not convinced, and I feel like it just complicates the validation / targetting / volume issues.

Are users allowed to dump submissions to nodes of their choice? With many SNs in the network all those submissions could be handled by (probably) tens of SNs simultaneously right?
Assuming the jobs are being spread evenly between all SNs, is it really a problem at all?
Bgjjj2016
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250

Ben2016


View Profile
April 12, 2017, 10:24:02 AM
 #5005

Hi everyone, how high the block height is supposed to go on Elastic Explorer ?

My " I want that Old Toyota Camry very bad" BTC Fund :1DQU4oqmZRcKSzg7MjPLMuHrMwnbDdjQRM
Join the Elastic revolution! Elastic Network: The Decentralized Supercomputer 
ELASTIC WEBSITE|ANNOUNCEMENT THREAD|JOIN THE SLACK
onemanatatime
Full Member
***
Offline Offline

Activity: 210
Merit: 100


Aluna.Social


View Profile WWW
April 12, 2017, 10:26:29 AM
 #5006

 When do these tokens finally launch? and any plans on which exchange ?

This time it's different.
coralreefer
Sr. Member
****
Offline Offline

Activity: 465
Merit: 260


View Profile
April 12, 2017, 11:57:57 AM
 #5007

Is queuing the right way to go at all?

I don't really see any way around it, but maybe some other bright minds around here can come up with a solution.

But the bottom line is we can easily have complex jobs that take considerable time to solve, and each submission would need to be validated.  For example, if I create a job that takes 0.1 sec to solve, and I dump 1000 submissions onto a SN, that node would be tied up for 2 minutes before it could do anything else.  And this will take place while people are dumping hundreds if not thousands of legitimate POW submissions on the SN.

I still don't know of a good solution...I still wish we didn't have POW in xel and just focused on bounties.  I know you'll say we need the POW logic ;-)  I'm just not convinced, and I feel like it just complicates the validation / targetting / volume issues.

Are users allowed to dump submissions to nodes of their choice? With many SNs in the network all those submissions could be handled by (probably) tens of SNs simultaneously right?
Assuming the jobs are being spread evenly between all SNs, is it really a problem at all?

Yes, I can target all my submission to a specific SN.  I'm not suggesting anyone do this, but it has to be accounted for that someone could do it.
ttookk
Hero Member
*****
Offline Offline

Activity: 994
Merit: 513


View Profile
April 12, 2017, 11:59:23 AM
 #5008

Is queuing the right way to go at all?

I don't really see any way around it, but maybe some other bright minds around here can come up with a solution.

But the bottom line is we can easily have complex jobs that take considerable time to solve, and each submission would need to be validated.  For example, if I create a job that takes 0.1 sec to solve, and I dump 1000 submissions onto a SN, that node would be tied up for 2 minutes before it could do anything else.  And this will take place while people are dumping hundreds if not thousands of legitimate POW submissions on the SN.

I still don't know of a good solution...I still wish we didn't have POW in xel and just focused on bounties.  I know you'll say we need the POW logic ;-)  I'm just not convinced, and I feel like it just complicates the validation / targetting / volume issues.

Are users allowed to dump submissions to nodes of their choice? With many SNs in the network all those submissions could be handled by (probably) tens of SNs simultaneously right?
Assuming the jobs are being spread evenly between all SNs, is it really a problem at all?

I think jobs must be checked by at least a portion of SNs, otherwise a SN could send bad jobs, be it by accident or with malicios intent. So, to check a SNs integrity, other SNs have to check what a SN does. Whether all SNs have to check all jobs, I don't know.
coralreefer
Sr. Member
****
Offline Offline

Activity: 465
Merit: 260


View Profile
April 12, 2017, 12:13:58 PM
 #5009

Is queuing the right way to go at all?

I don't really see any way around it, but maybe some other bright minds around here can come up with a solution.

But the bottom line is we can easily have complex jobs that take considerable time to solve, and each submission would need to be validated.  For example, if I create a job that takes 0.1 sec to solve, and I dump 1000 submissions onto a SN, that node would be tied up for 2 minutes before it could do anything else.  And this will take place while people are dumping hundreds if not thousands of legitimate POW submissions on the SN.

I still don't know of a good solution...I still wish we didn't have POW in xel and just focused on bounties.  I know you'll say we need the POW logic ;-)  I'm just not convinced, and I feel like it just complicates the validation / targetting / volume issues.

Are users allowed to dump submissions to nodes of their choice? With many SNs in the network all those submissions could be handled by (probably) tens of SNs simultaneously right?
Assuming the jobs are being spread evenly between all SNs, is it really a problem at all?

I think jobs must be checked by at least a portion of SNs, otherwise a SN could send bad jobs, be it by accident or with malicios intent. So, to check a SNs integrity, other SNs have to check what a SN does. Whether all SNs have to check all jobs, I don't know.

That is not correct, the current design does not require multiple SNs to validate a job..
ImI
Legendary
*
Offline Offline

Activity: 1946
Merit: 1019



View Profile
April 12, 2017, 12:34:08 PM
 #5010

Is queuing the right way to go at all?

I don't really see any way around it, but maybe some other bright minds around here can come up with a solution.

But the bottom line is we can easily have complex jobs that take considerable time to solve, and each submission would need to be validated.  For example, if I create a job that takes 0.1 sec to solve, and I dump 1000 submissions onto a SN, that node would be tied up for 2 minutes before it could do anything else.  And this will take place while people are dumping hundreds if not thousands of legitimate POW submissions on the SN.

I still don't know of a good solution...I still wish we didn't have POW in xel and just focused on bounties.  I know you'll say we need the POW logic ;-)  I'm just not convinced, and I feel like it just complicates the validation / targetting / volume issues.

Are users allowed to dump submissions to nodes of their choice? With many SNs in the network all those submissions could be handled by (probably) tens of SNs simultaneously right?
Assuming the jobs are being spread evenly between all SNs, is it really a problem at all?

I think jobs must be checked by at least a portion of SNs, otherwise a SN could send bad jobs, be it by accident or with malicios intent. So, to check a SNs integrity, other SNs have to check what a SN does. Whether all SNs have to check all jobs, I don't know.

SN are checked through guard-nodes afaik.
logictense
Hero Member
*****
Offline Offline

Activity: 1302
Merit: 511


View Profile WWW
April 12, 2017, 12:34:44 PM
 #5011

Is queuing the right way to go at all?

I don't really see any way around it, but maybe some other bright minds around here can come up with a solution.

But the bottom line is we can easily have complex jobs that take considerable time to solve, and each submission would need to be validated.  For example, if I create a job that takes 0.1 sec to solve, and I dump 1000 submissions onto a SN, that node would be tied up for 2 minutes before it could do anything else.  And this will take place while people are dumping hundreds if not thousands of legitimate POW submissions on the SN.

I still don't know of a good solution...I still wish we didn't have POW in xel and just focused on bounties.  I know you'll say we need the POW logic ;-)  I'm just not convinced, and I feel like it just complicates the validation / targetting / volume issues.

Are users allowed to dump submissions to nodes of their choice? With many SNs in the network all those submissions could be handled by (probably) tens of SNs simultaneously right?
Assuming the jobs are being spread evenly between all SNs, is it really a problem at all?

Is there any practical use for this? I mean are there any parties that would be interested in posting jobs that need solving to xel network? Is the a chance that there exists somebody - hypothetical person - that has nothing to do other than submitting dumb jobs while they can simply put an entire elastic thread on ignore and dont bother about it.

bspus
Legendary
*
Offline Offline

Activity: 1932
Merit: 1000



View Profile
April 12, 2017, 02:31:24 PM
 #5012

When do these tokens finally launch? and any plans on which exchange ?

Judging by the messages posted here between the devs and the problems they are facing, I'd say we are still months away

jeffthebaker
Legendary
*
Offline Offline

Activity: 1484
Merit: 1034


View Profile
April 12, 2017, 02:56:29 PM
 #5013

When do these tokens finally launch? and any plans on which exchange ?

Judging by the messages posted here between the devs and the problems they are facing, I'd say we are still months away

Honestly, not a huge issue. The more time spent making this project perfect, the more it'll be used and the more people will value it. I think a lot of people in the crypto world have very high hopes for what Elastic is going to be when it comes to fruition. Really excited to see what's to come.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
April 12, 2017, 04:43:44 PM
Last edit: April 12, 2017, 05:11:33 PM by Evil-Knievel
 #5014

Just thinking out loud: do we really need the bounty announcements in the new SN scheme?

It depends on how well the SN can handle a huge volume of submissions...but I believe it will have to do this either way.

Yesterday, I submitted a job that had an issue which allowed every pass of the interpreter to find a "Bounty", so the miner tried to send hundreds of submissions pretty quickly....this is something anyone could do (i.e. create a simple job that allows legitimate bounty submissions to spam the SN).

So I thought your original design had a small fee on each of these submissions, along with the announcement in order to deter this kind of behaviour.  But if you have another approach that simplifies things, I'd be all for it.



Well, first of all a job has a natural bounty limit ... submissions beyond this level are not permitted. But of course, there is a grace period between the submissions and their actual inclusion in the blockchain (or its unconfirmed transaction cache). In this time window it is possible to flood as much as you can. We could add a "SN rate limit" which would allow not more than x transactions per node per second.

What sucks more is the lack of direct feedback from the SN. Since we queue at the moment, the miner does not even know if his submission was dropped, accepted or denied. We really have to think this through! Is queuing the right way to go at all?

Btw: I could reproduce your bug today. I just could not yet find out why it happens.

Fixed that bug. We will have to make sure that hashes and multiplicators are at most 32 bytes long ... not 33 like it could happen before.

Fix is here: https://github.com/OrdinaryDude/elastic-core/commit/b95596e572af659cb7355a68643a58098579109f
Extra checks in API are here: https://github.com/OrdinaryDude/elastic-core/commit/4870aa5c22786e27fbfdc37665a45e82f99410c9

Do not use that yet!
coralreefer
Sr. Member
****
Offline Offline

Activity: 465
Merit: 260


View Profile
April 12, 2017, 07:12:47 PM
 #5015

Just thinking out loud: do we really need the bounty announcements in the new SN scheme?

It depends on how well the SN can handle a huge volume of submissions...but I believe it will have to do this either way.

Yesterday, I submitted a job that had an issue which allowed every pass of the interpreter to find a "Bounty", so the miner tried to send hundreds of submissions pretty quickly....this is something anyone could do (i.e. create a simple job that allows legitimate bounty submissions to spam the SN).

So I thought your original design had a small fee on each of these submissions, along with the announcement in order to deter this kind of behaviour.  But if you have another approach that simplifies things, I'd be all for it.



Well, first of all a job has a natural bounty limit ... submissions beyond this level are not permitted. But of course, there is a grace period between the submissions and their actual inclusion in the blockchain (or its unconfirmed transaction cache). In this time window it is possible to flood as much as you can. We could add a "SN rate limit" which would allow not more than x transactions per node per second.

What sucks more is the lack of direct feedback from the SN. Since we queue at the moment, the miner does not even know if his submission was dropped, accepted or denied. We really have to think this through! Is queuing the right way to go at all?

Btw: I could reproduce your bug today. I just could not yet find out why it happens.

Fixed that bug. We will have to make sure that hashes and multiplicators are at most 32 bytes long ... not 33 like it could happen before.

Fix is here: https://github.com/OrdinaryDude/elastic-core/commit/b95596e572af659cb7355a68643a58098579109f
Extra checks in API are here: https://github.com/OrdinaryDude/elastic-core/commit/4870aa5c22786e27fbfdc37665a45e82f99410c9

Do not use that yet!

Hi EK, can you please confirm if this was due to something the miner sent or is it an issue in only the core server?  I checked the miner code and I don't see how it could send more than 32 bytes.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
April 12, 2017, 08:11:48 PM
 #5016

Hi EK, can you please confirm if this was due to something the miner sent or is it an issue in only the core server?  I checked the miner code and I don't see how it could send more than 32 bytes.

Took me a few days to find out, but the bug was the following:

The core server only allows a hash of max. 32 byte length in the BountyAnnouncement transaction. When something longer than that was tried to be added, the hash was simply set to null:

Code:
PiggybackedProofOfBountyAnnouncement(final ByteBuffer buffer, final byte transactionVersion)
throws NxtException.NotValidException {
super(buffer, transactionVersion);
this.workId = buffer.getLong();
final short hashSize = buffer.getShort();

if ((hashSize > 0) && (hashSize <= Constants.MAX_HASH_ANNOUNCEMENT_SIZE_BYTES)) {
this.hashAnnounced = new byte[hashSize];
buffer.get(this.hashAnnounced, 0, hashSize);
} else {
this.hashAnnounced = null;
}

}

When signing such transaction, which came in from via HTTP, everything appearently went fine ... the core server just signed the BountyAnnouncement with empty hash and submitted it. The verification worked fine as well because Attachments have no verification themselves.

The problem happened in the rebroadcast. Imagine someone originally attached 33 bytes (instead of 32) in the hash, then the hash would be nulled - hash has length zero. But the original transaction is still broadcast in its original form causing 33 extra "unexpected bytes" to be over after parsing the TX. This is what the error that you posted earlier stated.

I fixed it and learned ... variable length input sucks a lot. Tried to port many features to fixed length inputs (as you can see from my commits today).

However, 33 bytes must have come from somewhere, i.e., the miner. I suspect an extra byte for a minus sign maybe?

coralreefer
Sr. Member
****
Offline Offline

Activity: 465
Merit: 260


View Profile
April 12, 2017, 09:05:12 PM
 #5017

Hi EK, can you please confirm if this was due to something the miner sent or is it an issue in only the core server?  I checked the miner code and I don't see how it could send more than 32 bytes.

Took me a few days to find out, but the bug was the following:

The core server only allows a hash of max. 32 byte length in the BountyAnnouncement transaction. When something longer than that was tried to be added, the hash was simply set to null:

Code:
PiggybackedProofOfBountyAnnouncement(final ByteBuffer buffer, final byte transactionVersion)
throws NxtException.NotValidException {
super(buffer, transactionVersion);
this.workId = buffer.getLong();
final short hashSize = buffer.getShort();

if ((hashSize > 0) && (hashSize <= Constants.MAX_HASH_ANNOUNCEMENT_SIZE_BYTES)) {
this.hashAnnounced = new byte[hashSize];
buffer.get(this.hashAnnounced, 0, hashSize);
} else {
this.hashAnnounced = null;
}

}

When signing such transaction, which came in from via HTTP, everything appearently went fine ... the core server just signed the BountyAnnouncement with empty hash and submitted it. The verification worked fine as well because Attachments have no verification themselves.

The problem happened in the rebroadcast. Imagine someone originally attached 33 bytes (instead of 32) in the hash, then the hash would be nulled - hash has length zero. But the original transaction is still broadcast in its original form causing 33 extra "unexpected bytes" to be over after parsing the TX. This is what the error that you posted earlier stated.

I fixed it and learned ... variable length input sucks a lot. Tried to port many features to fixed length inputs (as you can see from my commits today).

However, 33 bytes must have come from somewhere, i.e., the miner. I suspect an extra byte for a minus sign maybe?



Thx for the explanation.  Many months back we had this same issue and it was due to a negative sign in the miner...thought I got rid of that issue.  I'll take a look again and get it fixed.
Ergenekon
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
April 13, 2017, 02:03:09 AM
 #5018


https://www.youtube.com/watch?v=suIHmqXVfTg

Start the game already!!

Bgjjj2016
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250

Ben2016


View Profile
April 13, 2017, 02:30:09 AM
 #5019

I see clear communication among our wonderful devs, along with their solid determination and efforts.... All great for good news to arrive soon  Smiley

My " I want that Old Toyota Camry very bad" BTC Fund :1DQU4oqmZRcKSzg7MjPLMuHrMwnbDdjQRM
Join the Elastic revolution! Elastic Network: The Decentralized Supercomputer 
ELASTIC WEBSITE|ANNOUNCEMENT THREAD|JOIN THE SLACK
BTCspace
Hero Member
*****
Offline Offline

Activity: 826
Merit: 501


View Profile
April 13, 2017, 03:25:21 AM
 #5020


haha that's funny.

running farm worldwide
Pages: « 1 ... 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 [251] 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 ... 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!