Version 4.x & Beyond - Feature Request

Development & Technical discussion about Timekoin.
Forum rules
Bug Collecting Database is Click Here
GitHub Account is Click Here
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: Version 4.x & Beyond - Feature Request

Post by KnightMB »

warmach wrote:Why not have the version built into blockchain? Create a network transaction that lists the current version, minimum version, and an effective time? This would allow a unified minimum version and a time when this version information would be enforced. I would guess this transaction would need to come from a specific account hard coded into software. Not sure how else to do that.

If someone is going to modify code to lie about their version, I think there will be bigger problems. This user is likely to try and exploit the network and their minimum version is probably the least of our worries.

We could build the server's current version into the currency generation. While it will not cover "client" setups, the main network servers would me the most important to have at the proper level since they essential maintain the network. A valid currency generation transaction would need to have the appropriate version checked against the version effective time.

It makes sense in my head, but let me know if what is written here needs clarified.
Yeah, I understand how it could be stored where no one could modify it and only said server could create it, but the initial issue is the server that creates the transaction with the vital info can basically say whatever it likes and the other peers would just have to believe it. We would need some type of mathematical way to prove that your server and my server both have the same "version" such as making a big hash out of all the code for example. That way, if even one thing is different somewhere, the hash outputs won't match and it would be possible to tell that server A isn't running the same software that server B is.
User avatar
PoisonWolf
Posts: 186
Joined: Fri Apr 12, 2013 10:39 am

Re: Version 4.x & Beyond - Feature Request

Post by PoisonWolf »

KnightMB wrote:
warmach wrote:Why not have the version built into blockchain? Create a network transaction that lists the current version, minimum version, and an effective time? This would allow a unified minimum version and a time when this version information would be enforced. I would guess this transaction would need to come from a specific account hard coded into software. Not sure how else to do that.

If someone is going to modify code to lie about their version, I think there will be bigger problems. This user is likely to try and exploit the network and their minimum version is probably the least of our worries.

We could build the server's current version into the currency generation. While it will not cover "client" setups, the main network servers would me the most important to have at the proper level since they essential maintain the network. A valid currency generation transaction would need to have the appropriate version checked against the version effective time.

It makes sense in my head, but let me know if what is written here needs clarified.
Yeah, I understand how it could be stored where no one could modify it and only said server could create it, but the initial issue is the server that creates the transaction with the vital info can basically say whatever it likes and the other peers would just have to believe it. We would need some type of mathematical way to prove that your server and my server both have the same "version" such as making a big hash out of all the code for example. That way, if even one thing is different somewhere, the hash outputs won't match and it would be possible to tell that server A isn't running the same software that server B is.
This is a marvelous idea. Perhaps once an hour, an RSA encryption is done for each timekoin .php file, and then the combination of all the RSA-keys are hashed with SHA256 to get a single value, and then this value is broadcasted across the network?
warmach
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Re: Version 4.x & Beyond - Feature Request

Post by warmach »

KnightMB wrote:
warmach wrote:Why not have the version built into blockchain? Create a network transaction that lists the current version, minimum version, and an effective time? This would allow a unified minimum version and a time when this version information would be enforced. I would guess this transaction would need to come from a specific account hard coded into software. Not sure how else to do that.

If someone is going to modify code to lie about their version, I think there will be bigger problems. This user is likely to try and exploit the network and their minimum version is probably the least of our worries.

We could build the server's current version into the currency generation. While it will not cover "client" setups, the main network servers would me the most important to have at the proper level since they essential maintain the network. A valid currency generation transaction would need to have the appropriate version checked against the version effective time.

It makes sense in my head, but let me know if what is written here needs clarified.
Yeah, I understand how it could be stored where no one could modify it and only said server could create it, but the initial issue is the server that creates the transaction with the vital info can basically say whatever it likes and the other peers would just have to believe it. We would need some type of mathematical way to prove that your server and my server both have the same "version" such as making a big hash out of all the code for example. That way, if even one thing is different somewhere, the hash outputs won't match and it would be possible to tell that server A isn't running the same software that server B is.
I get what you mean but couldn't SHA hash value be sent to the network just as easily as the version number? I'd just store the expected hash value in the DB and then modify the code to return the hash value.

I'm not a big fan of the file hash stuff. It makes it hard for independent development. Here is my example. I added a few lines of code that automagically redirect the login screen to HTTPS so that you don't accidentally hit the unsecured login. It is 4 lines of code that I want for my own security. This security method prevents me from doing this. Doing this locks independent development into the plugin environment. What if someone wrote a new native python client? It wouldn't work.
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: Version 4.x & Beyond - Feature Request

Post by KnightMB »

There is also (just thought of this), you could still create a server that just reports what the others want it to say (whatever the SHA256 hash was suppose to be) and thus defeat the issue of it anyway with different code running and doing someone else completely different. Really, the only way to keep honest servers honest is to follow the protocol rules.
User avatar
PoisonWolf
Posts: 186
Joined: Fri Apr 12, 2013 10:39 am

Re: Version 4.x & Beyond - Feature Request

Post by PoisonWolf »

KnightMB wrote:There is also (just thought of this), you could still create a server that just reports what the others want it to say (whatever the SHA256 hash was suppose to be) and thus defeat the issue of it anyway with different code running and doing someone else completely different. Really, the only way to keep honest servers honest is to follow the protocol rules.
You're right Knight. If a person intends on being malicious to the network, I'm sure there are ways to circumvent no matter the strategies that we could implement. If we go all out in trying to predict everything, I'd imagine we'd end up with a very closed down server software (i.e., closed source .exe or .jar file).

How about instead of trying to have plan for the worst and automatically have bad peers be kicked, we simply focus more on what I originally posted...which is just getting the server information/version? We will let server operators decide on what they want to do with the information, be it if they can trust it or not. However, we definitely do NOT have any protocols depend on what server versions are being reported. Version numbers are simply provided as an informative tool to the server admins.
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: Version 4.x & Beyond - Feature Request

Post by KnightMB »

PoisonWolf wrote:
KnightMB wrote:There is also (just thought of this), you could still create a server that just reports what the others want it to say (whatever the SHA256 hash was suppose to be) and thus defeat the issue of it anyway with different code running and doing someone else completely different. Really, the only way to keep honest servers honest is to follow the protocol rules.
You're right Knight. If a person intends on being malicious to the network, I'm sure there are ways to circumvent no matter the strategies that we could implement. If we go all out in trying to predict everything, I'd imagine we'd end up with a very closed down server software (i.e., closed source .exe or .jar file).

How about instead of trying to have plan for the worst and automatically have bad peers be kicked, we simply focus more on what I originally posted...which is just getting the server information/version? We will let server operators decide on what they want to do with the information, be it if they can trust it or not. However, we definitely do NOT have any protocols depend on what server versions are being reported. Version numbers are simply provided as an informative tool to the server admins.
I agree with that 100%, provide the tools and let the admins do what they want to work together.

I haven't had the time to research it all out, but I did want to write some plugins that would function has kind of a command center for the server admin that could provide some detailed analysis of other peers and maybe have some type of automated warnings to the admin if a large influx of peers come in all from the same IP range or if a large influx of peers come in all reporting inaccurate transaction history, etc. as an example.
collapse
Posts: 38
Joined: Sun Apr 21, 2013 2:44 pm

Re: Version 4.x & Beyond - Feature Request

Post by collapse »

transaction_history hash seems not unique, it's correct?

Code: Select all

MariaDB [timekoin]> SELECT COUNT(hash) from `transaction_history`;
+-------------+
| COUNT(hash) |
+-------------+
|     3330745 |
+-------------+
1 row in set (0.00 sec)

MariaDB [timekoin]> SELECT COUNT(DISTINCT hash) from `transaction_history`;
+----------------------+
| COUNT(DISTINCT hash) |
+----------------------+
|              3326648 |
+----------------------+
1 row in set (1 min 19.83 sec)
My TK public key:

Code: Select all

LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlIZk1BMEdDU3FHU0liM0RRRUJBUVVBQTRITkFEQ0J5UUtCd1FEQVZnL0w2OHorWUdab3dRRC92Sy93UmcwZDZLQlNoOG1DcFUzQwppZ1N4RjV4UUFMVUFWTEk4eElEUTFpTXFnUVlBanp3OFBGd1NtT0U2blpOV3dxSjVDeFRibS96NS9iQVZONnNNMys0M0VqdEZFdmhpCkxpNmhnZU9TWE05ZmsvNmlCSFQxQ0pnOVZiS25uRVlhemU1cHVKRHhtM0pWSlNZWGhNNHpqY2plMERsV1Fta1ArNnB2bTVZNkwxbEkKSHFaT0ZwdEZWV3dnVzE0NDFyd0E0MDU5YVJPOEJEbDZhS3VzWTVDblhPQnNLU251dGVUS1hHU1htK3FFam91M0dzVUNBd0VBQVE9PQotLS0tLUVORCBQVUJMSUMgS0VZLS0tLS0=
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: Version 4.x & Beyond - Feature Request

Post by KnightMB »

Yes, those 4097 duplicates can come about because only transactions need unique SHA256 outputs per transaction, but the SHA256 of a transaction cycle could be the same if the data being put into the SHA256 hash was identical/similar enough to somewhere else in the past. It is also known that when creating a hash that is smaller than the possible input data, you can produce duplicates (collisions) as well. SHA256 only produces a 64 character hash. So, anything less than 64 characters will in theory never have a collision, you'll always get a unique hash. Anything bigger, the more data you feed in, the more likely that a collision could happen. Timekoin feeds a lot of data into the SHA256 when making transaction foundations and transaction cycle hashes. That is why it only checks for duplicate transaction hashes. Otherwise, some weird product of data might make a transaction cycle from 4 years ago hash to the same one today and if a unique one was required, it would halt Timekoin due to the error.

A good read about it here:
https://en.wikipedia.org/wiki/Collision_resistance
User avatar
koinmaster
Posts: 357
Joined: Mon Jun 18, 2012 8:07 pm

Re: Version 4.x & Beyond - Feature Request

Post by koinmaster »

Was there some bug report from years ago about this? I remember something about someone trying to clone transactions and made a fuss about not being able to do exactly what you just said. :lol:
I don't think they realize that clone transactions would be an exploit, not a feature.
collapse
Posts: 38
Joined: Sun Apr 21, 2013 2:44 pm

Re: Version 4.x & Beyond - Feature Request

Post by collapse »

Code: Select all

MariaDB [timekoin]> select count(*) from transaction_history where public_key_to = public_key_from;
+----------+
| count(*) |
+----------+
|  3317379 |
+----------+
1 row in set (1 min 46.36 sec)

MariaDB [timekoin]> select count(*) from transaction_history where public_key_to != public_key_from;
+----------+
| count(*) |
+----------+
|    17248 |
+----------+
1 row in set (2 min 5.78 sec)

MariaDB [timekoin]> select count(distinct(public_key_to)) from transaction_history;
+--------------------------------+
| count(distinct(public_key_to)) |
+--------------------------------+
|                           1110 |
+--------------------------------+
1 row in set (6 min 33.85 sec)

MariaDB [timekoin]> select count(distinct(public_key_from)) from transaction_history;
+----------------------------------+
| count(distinct(public_key_from)) |
+----------------------------------+
|                              779 |
+----------------------------------+
1 row in set (2 min 44.67 sec)


MariaDB [timekoin]> select count(*) from transaction_history where public_key_to = '01110100011010010110110101100101';
+----------+
| count(*) |
+----------+
|   392042 |
+----------+
1 row in set (5 min 22.52 sec)

Public keys:

Public key size = 360 bytes
Known addresses, less than 1889, near to 1110. Size of info 399.6kBytes

"Real" transactions 17248.
Size in database: 3334779 * 2 * 360 = 2.4 Gbytes
"Empty" bytes x2: 392042 * 32 * 2 = 25 Mbytes

Some data...
My TK public key:

Code: Select all

LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlIZk1BMEdDU3FHU0liM0RRRUJBUVVBQTRITkFEQ0J5UUtCd1FEQVZnL0w2OHorWUdab3dRRC92Sy93UmcwZDZLQlNoOG1DcFUzQwppZ1N4RjV4UUFMVUFWTEk4eElEUTFpTXFnUVlBanp3OFBGd1NtT0U2blpOV3dxSjVDeFRibS96NS9iQVZONnNNMys0M0VqdEZFdmhpCkxpNmhnZU9TWE05ZmsvNmlCSFQxQ0pnOVZiS25uRVlhemU1cHVKRHhtM0pWSlNZWGhNNHpqY2plMERsV1Fta1ArNnB2bTVZNkwxbEkKSHFaT0ZwdEZWV3dnVzE0NDFyd0E0MDU5YVJPOEJEbDZhS3VzWTVDblhPQnNLU251dGVUS1hHU1htK3FFam91M0dzVUNBd0VBQVE9PQotLS0tLUVORCBQVUJMSUMgS0VZLS0tLS0=
Post Reply