Antifragility - Revision history

Slackjore: typo

2019-01-26T17:20:16Z

typo

Slackjore: added comment

2019-01-26T16:41:29Z

added comment

Slackjore: added wikilink

2019-01-26T16:34:20Z

added wikilink

Slackjore: updated tps

2019-01-26T16:32:34Z

updated tps

Slackjore: updated name

2019-01-20T16:13:54Z

updated name

Punqtured: 2 revisions imported

2019-01-19T22:19:44Z

2 revisions imported

Slackjore: added wikilink; brief data about Feb tests

2018-03-12T08:54:30Z

added wikilink; brief data about Feb tests

Slackjore: copypasta from original Byteball wiki, author slackjore as usual

2018-03-11T18:06:00Z

copypasta from original Byteball wiki, author slackjore as usual

New page

==Why stress tests?==
Antifragility is a property of systems that increase in capability, resilience, or robustness as a result of stressors, shocks, volatility, noise, mistakes, faults, attacks, or failures. It is a concept developed by Professor Nassim Nicholas Taleb in his book, Antifragile and in technical papers. <ref>[https://en.wikipedia.org/wiki/Antifragility Wikipedia: Antifragility]</ref>

It applies to any cryptocurrency in that a coin's main platform must be frequently stress-tested as it matures, otherwise the live production will break unexpectedly, maybe with disastrous results. Sometimes, like an exchange being severely hacked, it can mean the end of that platform.

==Byteball stress tests==
These are community-produced tests, with no "team" input (at present). They are experiments.

===Jan 2018===
@portabella has agreed to do one "next week", i.e. Jan 7-13. He provided the address 3JI5LUOH755Y3XV2IYF25M2YG2MNHZST, but it is not clear what for.

The idea is to see if the platform can cope with a relatively large volume of transactions: 10 tps (transactions per second)? 50tps? 100tps? 500tps? 1000tps for 5 minutes?

What seems to be needed is an automated way of producing transactions on the platform, plus a huge number of confirmed inputs to draw from. Because of [https://byteroll.com/change-address change address] mechanics one cannot just pump transactions out of one single address.

====Sharing the script====
Maybe once @portabella has the script working, it could be shared with the 5-10 other "non-team" devs, and then all could fire away at the set time.

==Comment==
<blockquote>'''Tonych 2017-02-07:''' You know, there is no architectural limit in the DAGs. Regarding the practical limits, I don't buy into this race to Visa tps. The most pressing issue of crypto is not tps, it is adoption (which we address in the first place). Tps will come second after the first is solved.<ref>https://bitcointalk.org/index.php?topic=1608859.msg17789094#msg17789094</ref></blockquote>
==External links==

==References==
<references />
[[Category:Browse]]

@@ Line 4: / Line 4: @@
 It applies to any cryptocurrency in that a coin's main [[platform]] must be frequently stress-tested as it matures, otherwise the live production will break unexpectedly, maybe with disastrous results. Sometimes, such as an exchange being severely hacked, it can mean the end of that platform.
-==TPS (Transactions per second) ==
+==TPS Transactions per second ==
 === 2017 Comment ===
 <blockquote>'''Tonych 2017-02-07:''' You know, there is no architectural limit in the DAGs. Regarding the practical limits, I don't buy into this race to Visa tps. The most pressing issue of crypto is not tps, it is adoption (which we address in the first place). Tps will come second after the first is solved.<ref>https://bitcointalk.org/index.php?topic=1608859.msg17789094#msg17789094</ref></blockquote>

@@ Line 11: / Line 11: @@
 <blockquote>'''Tonych 2019-01-06:''' After recent optimizations, I synced a full node in 1.5 days, average speed 30 tps</blockquote>
-<blockquote>'''Punqtured 2019-01-26:''' [The 30 tps is for both syncing up a full node and active transactions.] The bottleneck is currently when a full [[node]] establishes order between transactions by looking at their positions in relation to transactions posted by witnesses. This re-ordering of transactions is what is currently the bottleneck. When a full node starts to syncronize, it does exactly the same re-ordering of units as it would [with] "new" units. The node receives the new units from the hub and establishes the main chain. So if the hub feeds a node 30 units per second from the past or feeds the node 30 units per second from the present, doesn't make any difference.
+<blockquote>'''Punqtured 2019-01-26:''' [The 30 tps is for both syncing up a full node and active transactions.] The bottleneck is currently when a full [[node]] establishes order between transactions by looking at their positions in relation to transactions posted by witnesses. This re-ordering of transactions is what is currently the bottleneck. When a full node starts to syncronize, it does exactly the same re-ordering of units as it would [with] "new" units. The node receives the new units from the hub and establishes the main chain. So if the hub feeds a node 30 units per second from the past or feeds the node 30 units per second from the present, doesn't make any difference.</blockquote>
 ==External links==

@@ Line 11: / Line 11: @@
 <blockquote>'''Tonych 2019-01-06:''' After recent optimizations, I synced a full node in 1.5 days, average speed 30 tps</blockquote>
-<blockquote>'''Punqtured 2019-01-26:''' [The 30tps is for both syncing up a full node and active transactions.] The bottleneck is currently when a full node establishes order between transactions by looking at their positions in relation to transactions posted by witnesses. This re-ordering of transactions is what is currently the bottleneck. When a full node starts to syncronize, it does exactly the same re-ordering of units as it would [with] "new" units. The node receives the new units from the hub and establishes the main chain. So if the hub feeds a node 30 units per second from the past or feeds the node 30 units per second from the present, doesn't make any difference.
+<blockquote>'''Punqtured 2019-01-26:''' [The 30 tps is for both syncing up a full node and active transactions.] The bottleneck is currently when a full [[node]] establishes order between transactions by looking at their positions in relation to transactions posted by witnesses. This re-ordering of transactions is what is currently the bottleneck. When a full node starts to syncronize, it does exactly the same re-ordering of units as it would [with] "new" units. The node receives the new units from the hub and establishes the main chain. So if the hub feeds a node 30 units per second from the past or feeds the node 30 units per second from the present, doesn't make any difference.
 ==External links==

@@ Line 1: / Line 1: @@
 ==Why stress tests?==
-Antifragility is a property of systems that increase in capability, resilience, or robustness as a result of stressors, shocks, volatility, noise, mistakes, faults, attacks, or failures. It is a concept developed by Professor Nassim Nicholas Taleb in his book, Antifragile and in technical papers. <ref>[https://en.wikipedia.org/wiki/Antifragility Wikipedia: Antifragility]</ref>
+Antifragility is a property of systems that increase in capability, resilience, or robustness as a result of stressors, shocks, volatility, noise, mistakes, faults, attacks, or failures. It is a concept developed by Professor Nassim Nicholas Taleb in his book ''Antifragile'' and in technical papers. <ref>[https://en.wikipedia.org/wiki/Antifragility Wikipedia: Antifragility]</ref>
-It applies to any cryptocurrency in that a coin's main [[platform]] must be frequently stress-tested as it matures, otherwise the live production will break unexpectedly, maybe with disastrous results. Sometimes, like an exchange being severely hacked, it can mean the end of that platform.
+It applies to any cryptocurrency in that a coin's main [[platform]] must be frequently stress-tested as it matures, otherwise the live production will break unexpectedly, maybe with disastrous results. Sometimes, such as an exchange being severely hacked, it can mean the end of that platform.
-==Obyte stress tests==
+==TPS (Transactions per second) ==
-These are community-produced tests, with no "team" input (at present). They are experiments.
+=== 2017 Comment ===
-===Jan 2018===
+=== 2019 Comments ===
-@portabella has agreed to do one "next week", i.e. Jan 7-13. He provided the address 3JI5LUOH755Y3XV2IYF25M2YG2MNHZST, but it is not clear what for.
+<blockquote>'''Tonych 2019-01-06:''' After recent optimizations, I synced a full node in 1.5 days, average speed 30 tps</blockquote>
-The idea is to see if the platform can cope with a relatively large volume of transactions: 10 tps (transactions per second)? 50tps? 100tps? 500tps? 1000tps for 5 minutes?
+<blockquote>'''Punqtured 2019-01-26:''' [The 30tps is for both syncing up a full node and active transactions.] The bottleneck is currently when a full node establishes order between transactions by looking at their positions in relation to transactions posted by witnesses. This re-ordering of transactions is what is currently the bottleneck. When a full node starts to syncronize, it does exactly the same re-ordering of units as it would [with] "new" units. The node receives the new units from the hub and establishes the main chain. So if the hub feeds a node 30 units per second from the past or feeds the node 30 units per second from the present, doesn't make any difference.
 ==External links==

@@ Line 4: / Line 4: @@
 It applies to any cryptocurrency in that a coin's main [[platform]] must be frequently stress-tested as it matures, otherwise the live production will break unexpectedly, maybe with disastrous results. Sometimes, like an exchange being severely hacked, it can mean the end of that platform.
-==Byteball stress tests==
+==Obyte stress tests==
 These are community-produced tests, with no "team" input (at present). They are experiments.

← Older revision	Revision as of 22:19, 19 January 2019
(No difference)

@@ Line 2: / Line 2: @@
 Antifragility is a property of systems that increase in capability, resilience, or robustness as a result of stressors, shocks, volatility, noise, mistakes, faults, attacks, or failures. It is a concept developed by Professor Nassim Nicholas Taleb in his book, Antifragile and in technical papers. <ref>[https://en.wikipedia.org/wiki/Antifragility Wikipedia: Antifragility]</ref>
-It applies to any cryptocurrency in that a coin's main platform must be frequently stress-tested as it matures, otherwise the live production will break unexpectedly, maybe with disastrous results. Sometimes, like an exchange being severely hacked, it can mean the end of that platform.
+It applies to any cryptocurrency in that a coin's main [[platform]] must be frequently stress-tested as it matures, otherwise the live production will break unexpectedly, maybe with disastrous results. Sometimes, like an exchange being severely hacked, it can mean the end of that platform.
 ==Byteball stress tests==
@@ Line 12: / Line 12: @@
 The idea is to see if the platform can cope with a relatively large volume of transactions: 10 tps (transactions per second)? 50tps? 100tps? 500tps? 1000tps for 5 minutes?
-What seems to be needed is an automated way of producing transactions on the platform, plus a huge number of confirmed inputs to draw from. Because of [https://byteroll.com/change-address change address] mechanics one cannot just pump transactions out of one single address.
+===Feb 2018===
+@seb486 did a series of 3 stress tests.
 ==Comment==