| 17 Jul 2018 |
 komodobridge | [discord] <blackjok3r> Testing the TxBlaster API over endurance is pointless, and I think this is why James said a 15 minute window of all chains with full blocks was all that was required.. I did have a single chain locally runnign for over 5H with full blocks though, so it can be run for a long time | 08:23:25 |
| komodobridge | [discord] <Mylo(KomodoPioneers)> OK - very specific goal. Got it. | 08:25:49 |
| komodobridge | [discord] <blackjok3r> However if you just want data to say a blockchain can run at full block capacity, you could just point to BTC at the end of last year... every block was full for months straight. | 08:26:48 |
| komodobridge | [discord] <blackjok3r> I dont see a need to prove what has already been proven. | 08:27:07 |
| komodobridge | [discord] <Mylo(KomodoPioneers)> OK fair point. | 08:29:39 |
| komodobridge | [discord] <Mylo(KomodoPioneers)> What has been the largest scale test tx/s to date? | 08:30:05 |
| komodobridge | [discord] <blackjok3r> The 1024 chain test. | 08:30:18 |
| komodobridge | [discord] <blackjok3r> but they were 100 pyamnt TX's so the 20,000 number is far lower than theortically possible. | 08:30:42 |
| komodobridge | [discord] <blackjok3r> The 256 chain test, to test kubernetes should eclipse that number easily... theoretical maximum is ~37k tx/s. | 08:32:27 |
| komodobridge | [discord] <blackjok3r> If we need higher than that we can use 512 chains to double it. | 08:33:12 |
| komodobridge | [discord] <blackjok3r> Either size will give us the data we need. | 08:33:31 |
| komodobridge | [discord] <Mylo(KomodoPioneers)> It's pretty much processing bytes of tx data across a decentralized chain cluster. Correct?
100 chains ~= 200MB/min
1000 chains = ~=2000MB/min
10000 chains = ~=20000MB/min | 08:50:52 |
| komodobridge | [discord] <Mylo(KomodoPioneers)>
https://cdn.discordapp.com/attachments/449949868904022036/468701212317843466/Screen_Shot_2018-07-17_at_6.50.21_pm.png | 08:51:17 |
| komodobridge | [discord] <Mylo(KomodoPioneers)> I want to build a template/HOWTO so others can take our work and implement their own test. | 08:51:48 |
| komodobridge | [discord] <Mylo(KomodoPioneers)> Possible now? Or some doc gaps to fill ? | 08:52:03 |
| komodobridge | [discord] <blackjok3r> for a single payment TX.... which is 1 vin to 2 vouts (your payment and the change returned to the first address) you can fit 8859 TX's into a 2MB block.
For a 100 payment TX, (1 vin to 101 vouts) you can fit 557 TX into a block. Anything inbwteeen should follow a fixed ratio, you can check this by creating some TX's and seeing how big the raw hex generated is.
Each chain can process on average 2MB per minute, | 09:21:15 |
| komodobridge | [discord] <blackjok3r> The transaction size also would work the other way, ie, combining 100 vins to 1 vout, to "join" the UTXO's back together. | 09:22:17 |
| komodobridge | [discord] <blackjok3r> With this data you can do math to work out how many chains is required to achieve any required amount and size of transactions. | 09:23:29 |
| komodobridge | [discord] <blackjok3r> My repo's would need some updating and some more docs for others to start at square 1, with no chains, and generate the JSON with the chain cluster parameters. But its not really that hard, with some updates to my scipts and docs, you can generate any number of chains in a cluster and all required scripts automatically to launch a notary node network to notarize them to KMD. | 09:26:27 |
| komodobridge | [discord] <blackjok3r> It took me about 2H from zero notary network to a network of 4, and min sigs for a notarization of 2. | 09:27:07 |
| komodobridge | [discord] <blackjok3r> In real world, I think min sigs would need to be more than 2 and notary nodes would need to be more than 4, however the compute resource required for these is pretty small. Biggest requirement is RAM. | 09:28:07 |
| komodobridge | [discord] <blackjok3r> In real world, I think min sigs would need to be more than 2 and notary nodes would need to be more than 4, however the compute resource required for these is pretty small. Biggest requirement is RAM and network bandwidth. | 09:28:17 |
| komodobridge | [discord] <Mylo(KomodoPioneers)> This is great, thanks heaps 🙏
So, with your engineers hat on - in case it wasn't 😛 , a "real world" use case would have multiple vin:vout combos and there'd be many more addresses. | 09:49:32 |
| komodobridge | [discord] <blackjok3r> Yes. | 09:49:45 |
| komodobridge | [discord] <blackjok3r> Which is why I think we should describe it as maximum payments, however even then, the size of the transactions will still vary and the amount of payments in a block will also vary. It totally depends on use case. Designing your cluster to run at capacity is also not clever, likey you would use 50-100% more chains than you 'need'. | 09:51:20 |
| komodobridge | [discord] <Mylo(KomodoPioneers)> Pretty much bytes processing throughput, with a handful of variables that us clever humans use to measure these concepts as payments and transactions.
Noted re: deployment rationale. | 09:54:48 |
| komodobridge | [discord] <smk762> Apologies fellas, my nbn is kaput, fault lodged awaiting resolution. Can do a bit via phone but kinda got one hand tied right now. | 11:59:08 |
| komodobridge | [discord] <blackjok3r> No worries, we are waiting on kubernetes stuff... AWS decided to make it harder than the google version to use for some reason. | 11:59:43 |
| komodobridge | [discord] <Mylo(KomodoPioneers)> nsa extensions | 12:17:28 |
| komodobridge | [discord] <Mylo(KomodoPioneers)> | 12:17:35 |
