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 »

PoisonWolf wrote:I have to ask...is it possible for Timekoin to become "bloated" like the current blocksize issue facing bitcoin's 1mb blocks? If we assume that TimeKoin will eventually become mainstream, will this be an issue down the road? I ask because if this will be an issue, can we come up with a dynamic solution right now such that the network will have built in code to auto-scale the transaction limitations based on the needs of the network.
The issue Bitcoin faces is actually 2 fold of the design. It pushes all network transactions into a 1 MB block and then does the random number guessing until it finds one that produces the largest target number. So as long as that process is completed every 10 minutes roughly, transactions flow through the queue just fine. The issue is that anyone in the bitcoin network can take a pool of transactions and produce the winning target number. Any transactions not in that winning block are basically queued up for the next 10 minutes. So, too many transactions filling up the 1 MB limit is one issue. The other issue is that someone in the bitcoin network can produce a block that has no transactions in it and still counted as valid. So now, everyone that had a transaction has to wait yet again another 10 minutes for someone else to try again. Take all these little issues and multiply them out when the transaction queue is already full and you have these exponentially higher waits where it might take 1, 2, or 3 hours to get the next block. In the mean time, transaction have been piling up like crazy, eventually I think they expire, not sure how that is handled now in bitcoin. That is whey you see a lot of articles around the web complaining about it.

Now, let's take the same situation and apply it to Timekoin. Nearly all PHP versions later than I think 2004 have the default input block size limit of 8 MB (the server administrator can set higher if they want like 16MB or 512MB even). So working off the default 8 MB input block size, assume it being used by all Timekoin servers. How many transactions can you queue up in 8 MB of space? The default transaction queue record is roughly 1,476 bytes long, so 8 MB would give us the ability for one server to send to another (8,000,000 / 1476 = ) 5,420 transaction records in one transmission. Timekoin currently does 1,000 records at a time. So even though more capacity exist, turning it on would be a matter of a code tweak to just do more transactions at once. 1,000 was chosen as a good, even cap for one transmission. If you server is communicating with multiple peers (which they usually all do), the effect is multiplied by every peer. Timekoin is also smart enough to only transfer copies of transaction records that it already does NOT have. That way, if 1001 transactions need to be processed, the first 1,000 queue don't need to be constantly sent around in the network over and over.

So given the ability to transfer thousands of records around to be processed, how many will Timekoin actually take in at once? Currently there is no set limit to how many to process at once. So if there were a million transactions and a fast enough server to process it, that would be the limit. But for a more realistic comparison, take a Digital Ocean bare minimum VPS and a Raspberry Pi. If you generate 500 transactions all from different keys, the Digital Ocean VPS usually burns through them in just a few seconds. The Raspberry Pi, closer to +30 seconds. That was from a test I did last year. So how does Timekoin cope with peers in which some are super fast and others, not so super fast? Well, the slower ones while processing transactions change their status to "PROC" which stands for processing. This lets the other peers know that this particular peer is still working and not to be bothered until finished. So the PROC message is basically a "I'm busy, please wait" signal to the rest of the network. When the peer is finally finished, then it generates the new transaction history hash and so the process for comparing history and transactions begin again for it, even if other peers are ahead of the game. What happens if a peer is really, really slow. Well, that is why peers are disconnected after 5 minutes of being idle, to coincide with the 5 minute transaction window of Timekoin. So if your peer isn't fast enough to keep up, it gets left behind by the rest of the network basically.
collapse
Posts: 38
Joined: Sun Apr 21, 2013 2:44 pm

Re: Version 4.x & Beyond - Feature Request

Post by collapse »

Migrate to postgres seems very difficult with code structure.

Code: Select all

mysql_result ( mysql_query ($args)) 
with:
function.php

Code: Select all

/**
* This function process a SQL query according to your database preferences.
* @param $args ....
*/
function sql_result($args){
...
mysql_result ( mysql_query (args));
...
}
}
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 »

I do have plans to offer up support for it in the future, just didn't want to include it in the 4.x series just yet to avoid trying to include too many new features at once for the new version. Timekoin only uses SELECT, INSERT, UPDATE, DELETE, and DROP commands in mySQL/MariaDB database, so moving to PostgreSQL is just not using the ' character in a lot of places. Timekoin doesn't use any special functions for mySQL so it makes a conversion to PostgreSQL that much easier. Granted, it is still a big task, but it isn't as bad as having to totally re-write the access language between the two.
collapse wrote:Migrate to postgres seems very difficult with code structure.

Code: Select all

mysql_result ( mysql_query ($args)) 
with:
function.php

Code: Select all

/**
* This function process a SQL query according to your database preferences.
* @param $args ....
*/
function sql_result($args){
...
mysql_result ( mysql_query (args));
...
}
}
User avatar
Smarty
Posts: 43
Joined: Mon Aug 19, 2013 5:40 pm

Re: Version 4.x & Beyond - Feature Request

Post by Smarty »

PoisonWolf wrote:Im really digging the 1 free transaction per 5 minute cycle. Anything beyond should be a cost of 1tk per transaction. I think the transaction fees should just go to a blackhole address. TK seriously needs some sort of deflationary mechanism.
It took me a while to read over this entire topic, so easy key cool stuff aside, I have to agree. Send the fee into pit that way no arguments about fairness has to come up if you put it into a public account. There will always be disagreements about how a public account should be spent. Since the reason is to discourage spam'n transactions, then it should disappear forever and if someone wants to spam until they have nothing left, let them be stupid like that. :lol:
User avatar
koinmaster
Posts: 357
Joined: Mon Jun 18, 2012 8:07 pm

Re: Version 4.x & Beyond - Feature Request

Post by koinmaster »

Smarty wrote:
PoisonWolf wrote:Im really digging the 1 free transaction per 5 minute cycle. Anything beyond should be a cost of 1tk per transaction. I think the transaction fees should just go to a blackhole address. TK seriously needs some sort of deflationary mechanism.
It took me a while to read over this entire topic, so easy key cool stuff aside, I have to agree. Send the fee into pit that way no arguments about fairness has to come up if you put it into a public account. There will always be disagreements about how a public account should be spent. Since the reason is to discourage spam'n transactions, then it should disappear forever and if someone wants to spam until they have nothing left, let them be stupid like that. :lol:
Easy key, cool with the idea, like how it removes a central point of attack against the server, fees for transactions, was kind of against the idea until I read further. I don't usually send 100 transactions all at once myself, so 1 free one is really a sweet spot for me, not like I couldn't just space it out if I really wanted to avoid fees. Maybe even have Timekoin do this automatically if you don't want to pay fees and there is no urgency to send those transactions immediately.
warmach
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Re: Version 4.x & Beyond - Feature Request

Post by warmach »

koinmaster wrote: Easy key, cool with the idea, like how it removes a central point of attack against the server, fees for transactions, was kind of against the idea until I read further. I don't usually send 100 transactions all at once myself, so 1 free one is really a sweet spot for me, not like I couldn't just space it out if I really wanted to avoid fees. Maybe even have Timekoin do this automatically if you don't want to pay fees and there is no urgency to send those transactions immediately.
Sounds like a great plugin to me!
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:
koinmaster wrote: Easy key, cool with the idea, like how it removes a central point of attack against the server, fees for transactions, was kind of against the idea until I read further. I don't usually send 100 transactions all at once myself, so 1 free one is really a sweet spot for me, not like I couldn't just space it out if I really wanted to avoid fees. Maybe even have Timekoin do this automatically if you don't want to pay fees and there is no urgency to send those transactions immediately.
Sounds like a great plugin to me!
Good point, should this just be an "Official" plugin or a part of the TK core structure? As a plugin, you can use it or not. Timekoin servers don't need to do anything extra and all the work is done by the people that want to use it.

A good transition could be "Use This Plugin for Easy Key because the easy key server will go offline at X.Y.Z date".
User avatar
joanofarc
Posts: 131
Joined: Sat Sep 08, 2012 8:09 am

Re: Version 4.x & Beyond - Feature Request

Post by joanofarc »

So this could be a plugin and nothing has to change for the timekoin code? I would want that because that would be more flexible. I am sure many are running tk servers don't really need to use an easy key at the server all the time, that is what the client would be better for. If anyone doesn't like how the plugin works, then they can write their own. I think a plugin would be a better idea because it won't tie up the "core" as you put it.
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:
koinmaster wrote: Easy key, cool with the idea, like how it removes a central point of attack against the server, fees for transactions, was kind of against the idea until I read further. I don't usually send 100 transactions all at once myself, so 1 free one is really a sweet spot for me, not like I couldn't just space it out if I really wanted to avoid fees. Maybe even have Timekoin do this automatically if you don't want to pay fees and there is no urgency to send those transactions immediately.
Sounds like a great plugin to me!
Good point, should this just be an "Official" plugin or a part of the TK core structure? As a plugin, you can use it or not. Timekoin servers don't need to do anything extra and all the work is done by the people that want to use it.

A good transition could be "Use This Plugin for Easy Key because the easy key server will go offline at X.Y.Z date".
I think we are talking about two different plugins. An easy key plugin I think is good to manage the process and it should be an official plugin. A plugin would allow a different update path and not be tied to the core protocol/server.

The other is a plugin to delay transactions so you don't have to pay a fee. That one should be a community driven plugin as I could see different requirements popping up. It would also be less code to maintain for the core team.
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:I think we are talking about two different plugins. An easy key plugin I think is good to manage the process and it should be an official plugin. A plugin would allow a different update path and not be tied to the core protocol/server.

The other is a plugin to delay transactions so you don't have to pay a fee. That one should be a community driven plugin as I could see different requirements popping up. It would also be less code to maintain for the core team.
I agree, that would speed up the v4.x release since it would only be down to code tweaks, removing legacy code not used anymore and fixing any issues that might be affecting server administrators (like the suPHP issue). The official plugin can come out at the same time so people can begin using it. Then some kind of timeline to sunset the old easy key server and remove reliance on it for key name translation.
Post Reply