Segwit details? N + 2*numtxids + numvins > N, segwit uses more space than 2MB HF - page 6.

2112

legendary

Activity: 2128

Merit: 1073

Quote from: JorgeStolfi on March 19, 2016, 05:48:52 PM

Pre-signed but unbroadcast or unconfirmed transactions seem to be a tough problem.

I disagree on the "tough" part. In my opinion this is less difficult than DOSbox/Wine on Linux or DOS subsystem in Windows 32 (and Itanium editions of Windows 64). It is more of the problem how much energy to spend on scoping the required area of backward compatibility and preparing/verifying test cases.

The initial step is already done in form of libconsensus. It is a matter of slightly broadening the libconsensus' interface to allow for full processing of compatibility-mode transactions off the wire and old-style blocks out of the disk archive.

Then it is just a matter of keeping track of the versions of libconsensus.

To my nose this whole "segregated witness as a soft fork" has a strong whiff of the "This program cannot be run in DOS mode" from Redmond, WA. Initially there were paeans written about how great it is that one could start Aldus Pagemaker both by typing PAGEMKR on the C> prompt (to start Windows) and by clicking PageMaker icon in the Program Manager (if you already had Windows started). Only years later the designers admitted this to be one of the worst choices in the history of backward compatibility.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: JorgeStolfi on March 19, 2016, 05:48:52 PM

Pre-signed but unbroadcast or unconfirmed transactions seem to be a tough problem.
...
TL;DR: Holding on to pre-signed transactions,without broadcasting them, seem to be a bad idea. There is no way to guarantee that a transaction will be confirmed, until it is confirmed. The older the transaction, the greater the risk of it becoming invalid.

maybe I am being a bit simplistic about this, but "unconfirmed" to me means that it hasnt been confirmed. So to require that all unconfirmed transactions must be confirmed contradicts the fundamental meaning of unconfirmed. What is the meaning of the word 'unconfirmed'?

If all mempool tx that are unconfirmed, must be confirmed, then doesnt the confirmation point move to being accepted in the mempool? We would then need to say that all zeroconf tx in the mempool are actually confirmed?

But if that is the case, then how can there be consensus about what tx are confirmed or not? If being in the mempool means its confirmed, we would need to enforce mempool consensus. Is that currently the case? Why is this a requirement? Is the whole point of blocks to have something to consensus on?

I think things are difficult enough without requiring any solution to also treat unconfirmed tx as confirmed.

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Pre-signed but unbroadcast or unconfirmed transactions seem to be a tough problem.

If the protocol is to support such transactions, then soft forks must be forbidden, since (by definition) transactions that were valid before a soft fork may be invalid after it. BIP66 invalidated any unbroadcast transactions that used the signature variants that it excluded. Even the deployment of SegWit as a soft fork could invalidate some valid transactions.

IMHO, the safest way to introduce changes is by a clean fork: making sure that *every* transaction or block that is valid under the old rules is invalid under the new ones, and vice-versa. The code for the change should be introduced in some release N of the software, but the change itself should be programmed to become active at some block number X that is ~6 months in the future, after the expected date of release N+3. Then users can be warned of the impending fork at the time of release N, and in particular that any transaction created with older releases that is not confirmed by block X will never be confirmed.

This does not solve completely the problem of transactions that are created specifically for delayed broadcast, but reduces the severity. Clients who need that feature can tell their new wallet software, after upgrading to release N, whether they intend to bradcast them before or after block X. (Or they can create both versions, just in case.)

The problem is that soft forks cannot be prevented. If a simple majority of the miners wants to impose a soft-fork type of change, all they have to do is to start rejecting all blocks and transactions that are invalid under their chosen new rules. They don't even have to warn other miners, users, or relay nodes; and even if they do, there is nothing that these players can do to prevent the fork.

TL;DR: Holding on to pre-signed transactions,without broadcasting them, seem to be a bad idea. There is no way to guarantee that a transaction will be confirmed, until it is confirmed. The older the transaction, the greater the risk of it becoming invalid.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: jl777 on March 19, 2016, 04:44:21 PM

The point is that I dont see any huge outcry if a tx is limited to say 1024 vins/vouts or some such number. If that avoids the N*N behavior it seems a simple way.

Well it could be done but I don't think that it would be liked, probably depends on who proposed it. At that point, it becomes political and not technical. Some would say that we shouldn't make the possibilities that you can do less than what can currently be done. Others may not. It becomes political whether to put a limit or not.

Quote from: jl777 on March 19, 2016, 04:44:21 PM

On the non-malleable txid basis, I cant find issues with T. Nolan's approach and any need for internal lookup tables, is a local implementation matter, right? And should limitations of existing implementations constrain improving the protocol?

Well local implementation does kind of matter. If it is something that is extremely difficult to implement, it probably isn't optimal. If it places additional system requirements, to use, it might not be something that we want to do. Of course, it can be implementation specific, but if implementing it can only be done in a few specific ways, then I don't think it should be done.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: achow101 on March 19, 2016, 04:34:41 PM

Quote from: molecular on March 19, 2016, 04:16:06 PM

Quote from: jl777 on March 19, 2016, 03:11:46 PM

If N squared performance assumes a single giant transaction, why not a rule to limit the size of a transaction?

Seems like a no-brainer. I've been looking through the commits, but couldn't find it. I think classic has a defense along those lines.

Even so, a 1 Mb transaction can still take a while to validate. A hypothetical scenario described here: https://bitcointalk.org/?topic=140078 states that a transaction of 1 Mb could take up to 3 minutes to verify. In reality, there was a roughly 1 Mb transaction that took about 25 seconds to verify described here: http://rusty.ozlabs.org/?p=522. Anything that is over a few seconds is quite a long time in computer standards. Now, both of those scenarios are less likely to happen now since libsecp256k1 introduced significantly faster signature validation, but it is still vulnerable to such attacks. A maliciously crafted 1 Mb transaction could, in theory, still take 25 seconds or longer to verify.

The point is that I dont see any huge outcry if a tx is limited to say 1024 vins/vouts or some such number. If that avoids the N*N behavior it seems a simple way.

On the non-malleable txid basis, I cant find issues with T. Nolan's approach and any need for internal lookup tables, is a local implementation matter, right? And should limitations of existing implementations constrain improving the protocol?

just a question about tradeoffs.

If the position is that anything that requires retooling the codebase to handle the increased load in the future is not acceptable, ok, just say so. After all, I dont want to be shamed again by suggesting that the current code isnt absolutely perfect in all ways possible. Just want to know what the groundrule are. If the current codebase is sacred then it changes the analysis of what is and isnt possible. Who am I to suggest making any code changes to the people that are 100x smarter than me.

James

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: molecular on March 19, 2016, 04:16:06 PM

Seems like a no-brainer. I've been looking through the commits, but couldn't find it. I think classic has a defense along those lines.

The rule for classic is to directly limit the amount of hashing required. If your block does more than 1.3GB of hashing, it is invalid. I assume that the 1.3GB limit is sufficient for a 1MB transaction. Ideally, any valid version 1 transaction (so less than 1MB inherently) should be valid when rules are changed.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: molecular on March 19, 2016, 04:16:06 PM

Quote from: jl777 on March 19, 2016, 03:11:46 PM

If N squared performance assumes a single giant transaction, why not a rule to limit the size of a transaction?

Seems like a no-brainer. I've been looking through the commits, but couldn't find it. I think classic has a defense along those lines.

Even so, a 1 Mb transaction can still take a while to validate. A hypothetical scenario described here: https://bitcointalk.org/?topic=140078 states that a transaction of 1 Mb could take up to 3 minutes to verify. In reality, there was a roughly 1 Mb transaction that took about 25 seconds to verify described here: http://rusty.ozlabs.org/?p=522. Anything that is over a few seconds is quite a long time in computer standards. Now, both of those scenarios are less likely to happen now since libsecp256k1 introduced significantly faster signature validation, but it is still vulnerable to such attacks. A maliciously crafted 1 Mb transaction could, in theory, still take 25 seconds or longer to verify.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: molecular on March 19, 2016, 04:16:06 PM

Quote from: jl777 on March 19, 2016, 03:11:46 PM

With regards to the O(N²) hashing operation. The transactions could simply have been limited to 1MB. This would have meant no changes at all. The O(N²) performance assumes that the block contains a single transaction.

If N squared performance assumes a single giant transaction, why not a rule to limit the size of a transaction?

Seems like a no-brainer. I've been looking through the commits, but couldn't find it. I think classic has a defense along those lines.

[/quote]
Since I am supposed to not have a brain, it explains

molecular

donator

Activity: 2772

Merit: 1019

Quote from: jl777 on March 19, 2016, 03:11:46 PM

With regards to the O(N²) hashing operation. The transactions could simply have been limited to 1MB. This would have meant no changes at all. The O(N²) performance assumes that the block contains a single transaction.

If N squared performance assumes a single giant transaction, why not a rule to limit the size of a transaction?
[/quote]

Seems like a no-brainer. I've been looking through the commits, but couldn't find it. I think classic has a defense along those lines.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: TierNolan on March 19, 2016, 02:33:53 PM

Quote from: achow101 on March 19, 2016, 07:47:03 AM

Additionally, on further thought, it will still require twice the lookup tables. There needs to be one for the transactions that version 1 txs can spend from and one for the version 2 txs. Version 2 txs still need to be able to reference the txid of a version 1 tx to spend from it or that ntxid for the version 1 tx also needs to be stored somewhere so it will increase the lookup table sizes.

I meant if you want to refer to a version 2 transaction, you use the n-txid. The reason that this is ok is that legacy/timelocked transactions are automatically version 1, so it doesn't make locked transactions suddenly unspendable.

Version 1 transactions would only refer to version 1 inputs (so no change)
Version 2 transactions would use txid when referring to version 1 inputs and n-txid when referring to version 2 inputs.

The nice feature of this is that n-txid don't need to recomputed back to the genesis block.

It is a hard-fork though. I should have been clearer. Given that SW can achieve the same with a soft fork, I think SW wins here.

Maybe SW should have happened in stages. The first stage could have been purely adding SW and no other changes (other than script versioning). Later script versions could add the new hashing rules.

In fairness, they have been trying to keep feature creep to a minimum.

With regards to the O(N²) hashing operation. The transactions could simply have been limited to 1MB. This would have meant no changes at all. The O(N²) performance assumes that the block contains a single transaction.

If N squared performance assumes a single giant transaction, why not a rule to limit the size of a transaction?

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: achow101 on March 19, 2016, 07:47:03 AM

Additionally, on further thought, it will still require twice the lookup tables. There needs to be one for the transactions that version 1 txs can spend from and one for the version 2 txs. Version 2 txs still need to be able to reference the txid of a version 1 tx to spend from it or that ntxid for the version 1 tx also needs to be stored somewhere so it will increase the lookup table sizes.

I meant if you want to refer to a version 2 transaction, you use the n-txid. The reason that this is ok is that legacy/timelocked transactions are automatically version 1, so it doesn't make locked transactions suddenly unspendable.

Version 1 transactions would only refer to version 1 inputs (so no change)
Version 2 transactions would use txid when referring to version 1 inputs and n-txid when referring to version 2 inputs.

The nice feature of this is that n-txid don't need to recomputed back to the genesis block.

It is a hard-fork though. I should have been clearer. Given that SW can achieve the same with a soft fork, I think SW wins here.

Maybe SW should have happened in stages. The first stage could have been purely adding SW and no other changes (other than script versioning). Later script versions could add the new hashing rules.

In fairness, they have been trying to keep feature creep to a minimum.

With regards to the O(N²) hashing operation. The transactions could simply have been limited to 1MB. This would have meant no changes at all. The O(N²) performance assumes that the block contains a single transaction.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: molecular on March 19, 2016, 07:01:40 AM

Mainly here I'm reacting to Maxwell saying txid change couldn't be deployed as a hardfork at all, because that quote very publicly being used on reddit to defend "segwit as a softfork".

Quote from: gmaxwell on March 16, 2016, 05:22:57 PM

Would it change how transaction IDs were computed, like elements alpha did? Doing so is conceptually simpler and might save 20 lines of code in the implementation... But it's undeployable: even as a hardfork-- it would break all software, web wallets, thin wallets, lite wallets, hardware wallets, block explorers-- it would break them completely, along with all presigned nlocktime transactions, all transactions in flight.

So that's basically FUD?

No. What he was responding to was th original idea of changing txid calculation entirely too something new. This idea (the second option) is instead introducing a new txid calculation method which will work alongside the original txid calculation algorithm.

Additionally, on further thought, it will still require twice the lookup tables. There needs to be one for the transactions that version 1 txs can spend from and one for the version 2 txs. Version 2 txs still need to be able to reference the txid of a version 1 tx to spend from it or that ntxid for the version 1 tx also needs to be stored somewhere so it will increase the lookup table sizes.

molecular

donator

Activity: 2772

Merit: 1019

Quote from: achow101 on March 19, 2016, 06:20:40 AM

Quote from: molecular on March 19, 2016, 03:09:37 AM

Quote from: TierNolan on March 18, 2016, 08:16:54 AM

Quote from: kn_b_y on March 18, 2016, 07:28:11 AM

One example gmaxwell gives: all presigned nlocktime transactions would be broken. For users keeping these in storage they may well represent a lot of security. Gone... the moment a new version of the software no longer sees the transaction as being valid.

You could have a rule that you can refer to inputs using either txid or normalized-txid. That maintains backwards compatibility. The problem is that you need twice the lookup table size. You need to store both the txid to transaction lookup and the n-txid to transaction lookup.

The rule could be changed so that transactions starting at version 2 using n-txid and version 1 transactions use txid. This means that each transaction only needs 1 lookup entry depending on its version number. If transaction 1 transactions cannot spend outputs from transaction 2 transactions, then the network will eventually update over time. It is still a hard-fork though.

Is that applicable / workable?

The first is possible but it is not optimal because it requires twice the lookup table size.

The second is also possible but the issue is the hard fork. The problem is that hard forks shouldn't be done often and for small things like this. It would be better if it was packaged with other stuff that is desired that also requires a hard fork. If also has less functionality than segwit.

Thanks for the info and those clarifications.

I understand you take issue with hardforking in general and I don't want to downplay the inherent risks.

I'm not suggesting to do a hard-fork just for this. I'm investigating the feasability of assembling a compromise package of changes. As you said:

Quote from: achow101 on March 19, 2016, 06:20:40 AM

It would be better if it was packaged with other stuff that is desired that also requires a hard fork.

Mainly here I'm reacting to Maxwell saying txid change couldn't be deployed as a hardfork at all, because that quote very publicly being used on reddit to defend "segwit as a softfork".

Quote from: gmaxwell on March 16, 2016, 05:22:57 PM

Would it change how transaction IDs were computed, like elements alpha did? Doing so is conceptually simpler and might save 20 lines of code in the implementation... But it's undeployable: even as a hardfork-- it would break all software, web wallets, thin wallets, lite wallets, hardware wallets, block explorers-- it would break them completely, along with all presigned nlocktime transactions, all transactions in flight.

So that's basically FUD?

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: molecular on March 19, 2016, 03:09:37 AM

Is the following suggestion a solution to that?

Quote from: JorgeStolfi on March 18, 2016, 10:33:00 AM

The position of a transaction in the blockchain should define which version of the rules is applicable to it

What keeps us from using the old way of calculating a txid for transactions in prefork-blocks and the new way after the fork?

Unconfirmed transactions are the issue. What do we do about transactions that were created just before the fork block? How do you distinguish between an unconfirmed transaction created prior to the fork and an unconfirmed transaction created after the fork block?

Quote from: molecular on March 19, 2016, 03:09:37 AM

Also, Tyler Nolan has a similar suggestion:

Quote from: TierNolan on March 18, 2016, 08:16:54 AM

Quote from: kn_b_y on March 18, 2016, 07:28:11 AM

One example gmaxwell gives: all presigned nlocktime transactions would be broken. For users keeping these in storage they may well represent a lot of security. Gone... the moment a new version of the software no longer sees the transaction as being valid.

The rule could be changed so that transactions starting at version 2 using n-txid and version 1 transactions use txid.
You could have a rule that you can refer to inputs using either txid or normalized-txid. That maintains backwards compatibility. The problem is that you need twice the lookup table size. You need to store both the txid to transaction lookup and the n-txid to transaction lookup.

The rule could be changed so that transactions starting at version 2 using n-txid and version 1 transactions use txid. This means that each transaction only needs 1 lookup entry depending on its version number. If transaction 1 transactions cannot spend outputs from transaction 2 transactions, then the network will eventually update over time. It is still a hard-fork though.

Is that applicable / workable?

The first is possible but it is not optimal because it requires twice the lookup table size.

The second is also possible but the issue is the hard fork. The problem is that hard forks shouldn't be done often and for small things like this. It would be better if it was packaged with other stuff that is desired that also requires a hard fork. If also has less functionality than segwit.

molecular

donator

Activity: 2772

Merit: 1019

The following was quoted on and linked from reddit:

Quote from: gmaxwell on March 16, 2016, 05:22:57 PM

If segwit were to be a hardfork? What would it be?

Would it change how transaction IDs were computed, like elements alpha did? Doing so is conceptually simpler and might save 20 lines of code in the implementation... But it's undeployable: even as a hardfork-- it would break all software, web wallets, thin wallets, lite wallets, hardware wallets, block explorers-- it would break them completely, along with all presigned nlocktime transactions, all transactions in flight. It would add more than 20 lines of code in having to handle the flag day. So while that design might be 'cleaner' conceptually the deployment would be so unclean as to be basically inconceivable. Functionally it would be no better, flexibility it would be no better. No one has proposed doing this.

Is the following suggestion a solution to that?

Quote from: JorgeStolfi on March 18, 2016, 10:33:00 AM

The position of a transaction in the blockchain should define which version of the rules is applicable to it

What keeps us from using the old way of calculating a txid for transactions in prefork-blocks and the new way after the fork?

------

Also, Tyler Nolan has a similar suggestion:

Quote from: TierNolan on March 18, 2016, 08:16:54 AM

Quote from: kn_b_y on March 18, 2016, 07:28:11 AM

One example gmaxwell gives: all presigned nlocktime transactions would be broken. For users keeping these in storage they may well represent a lot of security. Gone... the moment a new version of the software no longer sees the transaction as being valid.

You could have a rule that you can refer to inputs using either txid or normalized-txid. That maintains backwards compatibility. The problem is that you need twice the lookup table size. You need to store both the txid to transaction lookup and the n-txid to transaction lookup.

The rule could be changed so that transactions starting at version 2 using n-txid and version 1 transactions use txid. This means that each transaction only needs 1 lookup entry depending on its version number. If transaction 1 transactions cannot spend outputs from transaction 2 transactions, then the network will eventually update over time. It is still a hard-fork though.

Is that applicable / workable?

iCEBREAKER

legendary

Activity: 2156

Merit: 1072

Crypto is the separation of Power and State.

Quote from: jl777 on March 18, 2016, 09:51:45 PM

Quote from: achow101 on March 18, 2016, 09:50:20 PM

Quote from: jl777 on March 18, 2016, 07:08:27 PM

Are sigs in the witness data immune from malicious tx via lots of sigs?

I think they are since the transaction is hashed differently if the transaction uses witnesses. The different hashing method allows for faster hashes by using midstates which can be reused for every signature verification.

well that's good, but would be nice to see it explicitly instead of having to assume.

oh, thanks for the URL about segwit implementation, that helped me understand it a lot better

James

Explicitly stated here:

SF Bitcoin Devs Seminar: Key Tree Signatures
https://www.youtube.com/watch?v=gcQLWeFmpYg

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: achow101 on March 18, 2016, 09:50:20 PM

Quote from: jl777 on March 18, 2016, 07:08:27 PM

Are sigs in the witness data immune from malicious tx via lots of sigs?

I think they are since the transaction is hashed differently if the transaction uses witnesses. The different hashing method allows for faster hashes by using midstates which can be reused for every signature verification.

well that's good, but would be nice to see it explicitly instead of having to assume.

oh, thanks for the URL about segwit implementation, that helped me understand it a lot better

James

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: jl777 on March 18, 2016, 07:08:27 PM

Are sigs in the witness data immune from malicious tx via lots of sigs?

I think they are since the transaction is hashed differently if the transaction uses witnesses. The different hashing method allows for faster hashes by using midstates which can be reused for every signature verification.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: trashman43 on March 18, 2016, 07:52:50 PM

Quote from: jl777 on March 18, 2016, 07:08:27 PM

We could easily say SPV solves all signature attack problems. Just make it so your node doesnt do much at all and it avoids all these pesky problems, but the important issue to many people is what is the effect on full nodes. And by full, I mean a node that doesnt prune, relays, validates signatures and enables other nodes to do the bootstrapping.

Without that, doesnt bitcoin security model change to PoS level? I know how much you hate PoS

James

you paint the situation as if the binary options are 1. fully validating nodes (verify everything) and 2. thin clients (verify nothing). if we increase bandwidth pressure on nodes by increasing throughput capacity, then fully validating nodes can only switch to verifying nothing.

a much better solution is one that allows for fully validating nodes that would otherwise be forced off the network to partially validate -- whether by relaying blocks only, validating non-segwit tx, pruning data that is already under significant proof of work and therefore very likely secure. just because a pruned node cant bootstrap a new node doesnt mean it doesnt provide great value to the network.

are you suggesting that it would be better to simply force all these nodes off the network and into using trust-based protocols? because when you double bandwidth requirements and leave full nodes no other options, that's what happens.

there is a new term for this: "tradeoff denialism" Tongue

one could claim that increasing throughput doesnt mean pressuring nodes to shut down. but youd be living in denial, as throughput is directly related to bandwidth requirements

I am not saying that at all, but the question is if it is worth doubling the complexity of the code to process the blockchain, in order to have the intermediate "validates non-segwit tx" nodes. That appears to be the usecase that is created in this context.

So I ask you, is it worth doubling the amount of code dealing with signing and wtxid calculations to be able to have nodes that cant see a new class of segwit tx? In fact, what good is that as they cant see these tx. That is my point.

pruning nodes dont have a problem with HDD space now, so that is not an issue
validating nodes are still going to have to validate the witness data, unless they dont upgrade and cant even see them.

it just seems like a lot of work to get small benefit. Now if there was a new signature scheme that reduced the space required by 30% that comes with segwit, then it starts becoming like a tradeoff decision that can be made.

Right now the tradeoff is a lot of extra complexity for slightly less tx capacity than 2MB HF, I think a bit more CPU load too as the wtxid needs to be calculated.

I guess non-malleable txid is a good thing, but not including the signature in the txid calculation would achieve that too. The same segwit softfork trick can probably be used to surgically implement non-malleable signatures.

I just sense a lot bigger attack surface for minimal immediate functionality gains, especially as compared to alternate possibilities.

The following is test data from a test run I just did with iguana parallel sync:

Code:

  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:16:09  33845.10    529.20
02:16:10  22049.13    451.58
02:16:11  11677.73    228.16
02:16:12   9593.46    455.37
02:16:13   6336.21    343.45
02:16:14   5547.12    253.51
02:16:15   5571.61    443.59
02:16:16   8923.98    284.75
02:16:17   4965.57    329.09
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:16:18   2707.07    308.64
02:16:19   4556.55    531.37
02:16:20  23731.02    404.43
02:16:21  21888.67    578.04
02:16:22  34865.94    287.81
02:16:23   6858.57     84.74
02:16:24   7388.59    204.51
02:16:25  25366.26    358.41
02:16:26  14404.62    369.48
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:16:27   4309.20    210.68
02:16:28   2171.04    131.02
02:16:29   6415.35    541.98
02:16:30   5755.03    229.80
02:16:31   2871.57    104.28
02:16:32  31940.83    336.98
02:16:33   9254.67    296.59
02:16:34   3870.30    127.04
02:16:35   2311.22    151.33
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:16:36  40519.47    794.40
02:16:37  41520.63    599.23
02:16:38  20989.28    177.32
02:16:39   7380.14    119.51
02:16:40   3840.29     93.45
02:16:41   5518.21    273.35
02:16:42  21878.96    389.22
02:16:43  18944.35    205.19
02:16:44   8115.07    172.49
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:16:45   5995.48    247.25
02:16:46   3898.50     89.55
02:16:47   8779.15    342.28
02:16:48  17804.29    220.64
02:16:49  17875.56    150.98
02:16:50   6362.67     97.60
02:16:51  12898.52    280.99
02:16:52   4688.76    118.78
02:16:53  30455.30    429.20
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:16:54  22671.03    368.31
02:16:55  31944.43    453.90
02:16:56  15339.38    210.14
02:16:57  26194.08    392.04
02:16:58  32547.23    383.35
02:16:59  43963.34    403.81
02:17:00  56543.47    451.39
02:17:01  44521.50    393.46
02:17:02  15638.87    121.88
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:17:03   4431.99    105.13
02:17:04  36061.83    437.45
02:17:05  21794.80    185.65
02:17:06   4929.13     92.09
02:17:07  48649.40    458.98
02:17:08  51054.86    405.49
02:17:09  46497.26    364.73
02:17:10  52669.18    430.47
02:17:11  57609.61    454.50
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:17:12  53891.66    438.20
02:17:13  75635.86    893.06
02:17:14  30123.17    163.68
02:17:15  49683.16    444.59
02:17:16  47817.53    377.48
02:17:17  55363.33    461.86
02:17:18  43078.26    313.46
02:17:19  26149.84    278.79
02:17:20   6218.16    128.42
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:17:21  18398.26    250.10
02:17:22  33918.31    325.32
02:17:23  11346.06     92.86
02:17:24   3202.43     19.64
02:17:25   2052.03     46.51
02:17:26   2337.96     71.44
02:17:27   2207.81     65.98
02:17:28  23519.14    304.05
02:17:29  55862.76    415.71
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:17:30  47336.18    390.28
02:17:31  54468.87    494.74
02:17:32  56162.71    446.20
02:17:33  53209.51    359.89
02:17:34  49673.05    390.43
02:17:35  55885.92    390.03
02:17:36  53509.14    343.98
02:17:37  51986.69    342.46
02:17:38  45596.10    295.73
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:17:39  14180.28     92.42
02:17:40  39211.49    352.47
02:17:41  63358.33    454.38
02:17:42  56712.67    422.91
02:17:43  28156.47    264.18
02:17:44  30555.58    259.53
02:17:45  56936.93    455.36
02:17:46  59813.32    418.80
02:17:47  59308.36    441.71
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:17:48  59827.94    385.09
02:17:49  63606.64    430.43
02:17:50  59492.03    364.88
02:17:51  59679.47    427.00
02:17:52  51657.23    341.52
02:17:53  31356.31    240.92
02:17:54  55589.56    415.41
02:17:55  48241.90    359.84
02:17:56  52045.72    406.88
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:17:57  16252.14    123.89
02:17:58   3553.59     26.32
02:17:59   5630.81     43.69
02:18:00  51815.96    464.66
02:18:01  47686.79    314.43
02:18:02  60419.80    424.08
02:18:03  46624.46    330.34
02:18:04  47545.23    424.62
02:18:05  47507.25    385.20
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:18:06  47868.21    439.81
02:18:07  39462.08    344.86
02:18:08  47640.44    420.90
02:18:09  14381.75    143.29
02:18:10   5073.33     79.79
02:18:11  39820.47    392.17
02:18:12  16655.82    115.73
02:18:13   5446.54    171.00
02:18:14  34158.03    224.28
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:18:15   7642.00    100.28
02:18:16  63972.90    510.19
02:18:17  54716.79    418.07
02:18:18  55642.69    412.52
02:18:19  57620.22    421.78
02:18:20  51703.89    357.54
02:18:21  55794.66    395.24
02:18:22  74435.85    493.97
02:18:23  69177.78    413.13
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:18:24  35185.93    194.08
02:18:25  50689.11    370.72
02:18:26  54193.62    311.03
02:18:27  48325.34    334.62
02:18:28  40097.72    301.69
02:18:29  42524.21    348.53
02:18:30  29990.71    174.90
02:18:31  46417.99    393.07
02:18:32  49354.48    365.07
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:18:33  49785.06    354.96
02:18:34  58241.59    397.50
02:18:35  40331.71    208.12
02:18:36  38532.94    306.23
02:18:37  59926.13    462.11
02:18:38  55388.72    457.29
02:18:39  51891.44    362.08
02:18:40  58160.40    407.42
02:18:41  56494.46    375.54
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:18:42  58764.23    421.94
02:18:43  39135.91    299.46
02:18:44  54445.69    495.31
02:18:45  40178.11    275.20
02:18:46   9888.95     88.57
02:18:47   3974.48     60.40
02:18:48   5706.35     70.53
02:18:49   4687.59     50.77
02:18:50   2559.35     27.27
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:18:51   1300.63     20.38
02:18:52  53046.86    440.35
02:18:53  57797.57    408.33
02:18:54  53286.55    358.68
02:18:55  47007.64    307.33
02:18:56  44760.59    392.78
02:18:57  44529.40    328.03
02:18:58  55051.48    427.69
02:18:59  16109.61    124.49
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:19:00  64336.61    502.38
02:19:01  52468.14    306.32
02:19:02  55338.03    378.65
02:19:03  58055.49    387.75
02:19:04  33642.29    176.69
02:19:05  76283.29    658.32
02:19:06  26809.79    158.43
02:19:07  44293.91    285.87
02:19:08  16992.35     92.36
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:19:09   7930.64     52.08
02:19:10  18896.54    172.51
02:19:11  65831.62    458.27
02:19:12  59365.14    385.31
02:19:13  55428.89    368.86
02:19:14  66314.21    423.40
02:19:15  61998.23    378.79
02:19:16  41052.71    218.75
02:19:17  64654.85    481.15
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:19:18  48836.84    304.99
02:19:19  40473.96    294.56
02:19:20  78438.34    616.25
02:19:21  61219.32    220.61
02:19:22  68857.04    418.10
02:19:23  51494.45    328.57
02:19:24  61066.10    440.70
02:19:25  63359.72    403.87
02:19:26  61503.87    376.38
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:19:27  52609.02    341.24
02:19:28  62605.62    344.72
02:19:29  33506.52    213.18
02:19:30  61961.18    425.11
02:19:31  58548.41    419.69
02:19:32  67196.68    459.66
02:19:33  58272.33    325.00
02:19:34  36245.20    161.49
02:19:35  49304.49    321.84
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:19:36  69566.06    483.68
02:19:37  57570.63    257.62
02:19:38  30481.10    190.85
02:19:39  20689.72    120.54
02:19:40   9237.98    121.76
02:19:41  39236.86    279.72
02:19:42  86731.88    288.46
02:19:43  48629.80    156.77
02:19:44  26932.19    108.87
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:19:45  21396.59    127.82
02:19:46  14506.07     95.55
02:19:47  34846.09    372.36
02:19:48  67259.36    376.53
02:19:49  50631.76    295.99
02:19:50  58821.97    373.39
02:19:51  35396.34    180.00
02:19:52  17401.16    146.28
02:19:53  15857.72    120.87
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:19:54  55611.05    273.55
02:19:55  37599.18    151.61
02:19:56  48564.53    324.09
02:19:57  57451.85    290.47
02:19:58  54583.66    336.44
02:19:59  37948.65    169.34
02:20:00  48550.33    312.58
02:20:01  65724.29    423.13
02:20:02  60209.88    332.45
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:20:03  74052.36    500.69
02:20:04  64638.80    359.71
02:20:05  29832.36    195.49
02:20:06  17762.60    215.73
02:20:07  16180.92    199.96
02:20:08  13248.35    110.94
02:20:09   8491.46    142.89
02:20:10  57840.12    429.11
02:20:11  41637.34    164.31
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:20:12  22256.24    170.11
02:20:13  48529.94    397.18
02:20:14  62792.30    405.66
02:20:15  66254.80    484.94
02:20:16  67550.37    164.20
02:20:17  30034.56    109.21
02:20:18  23392.60    118.91
02:20:19  12935.04    152.88
02:20:20  72649.63    410.91
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:20:21  50598.86    248.77
02:20:22  38862.75    258.64
02:20:23  57587.91    363.20
02:20:24  65281.96    305.90
02:20:25  34910.63    182.79
02:20:26  37640.38    208.30
02:20:27  40726.89    221.85
02:20:28  51446.10    304.25
02:20:29  57708.71    296.97
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:20:30  56701.46    272.89
02:20:31  40277.95    242.45
02:20:32  60091.48    318.82
02:20:33  50029.19    340.54
02:20:34  51111.51    300.14
02:20:35  45111.85    261.23
02:20:36  64856.58    391.74
02:20:37  48861.61    217.04
02:20:38  43913.26    288.61
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:20:39  61526.10    300.26
02:20:40  47306.20    217.89
02:20:41  39147.65    276.59
02:20:42  74420.89    731.66
02:20:43  39885.88    214.77
02:20:44  19364.66    157.79
02:20:45  45577.97    270.80
02:20:46  51020.70    335.66
02:20:47  70866.59    360.11
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:20:48  62171.44    309.96
02:20:49  62204.88    344.18
02:20:50  61137.40    339.22
02:20:51  70663.35    376.55
02:20:52  55582.67    367.74
02:20:53  76263.89    400.27
02:20:54  63452.74    336.72
02:20:55  51701.00    225.72
02:20:56  44965.56    272.85
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:20:57  62732.16    328.52
02:20:58  73721.37    631.83
02:20:59  51871.17    241.76
02:21:00  46303.93    198.11
02:21:01  32508.94    213.94
02:21:02  73284.92    433.73
02:21:03  49834.10    252.62
02:21:04  63456.48    325.10
02:21:05  58625.35    260.59
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:21:06  35097.09    231.37
02:21:07  73310.38    379.32
02:21:08  61125.11    313.39
02:21:09  74764.18    536.69
02:21:10  58698.85    280.84
02:21:11  46448.25    176.45
02:21:12  59788.81    342.76
02:21:13  49127.29    286.97
02:21:14  61682.25    329.70
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:21:15  50247.67    292.26
02:21:16  45406.79    258.51
02:21:17  67076.83    337.77
02:21:18  60259.81    314.62
02:21:19  56777.60    299.90
02:21:20  42174.36    233.22
02:21:21  53835.24    338.31
02:21:22  68306.79    394.66
02:21:23  53365.89    269.94
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:21:24  57407.31    353.79
02:21:25  51447.38    240.82
02:21:26  46836.79    258.98
02:21:27  72469.32    692.14
02:21:28  37474.04    103.96
02:21:29  23530.95    108.24
02:21:30  16598.97     86.37
02:21:31  36923.23    290.40
02:21:32  67147.53    382.28
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:21:33  61126.80    252.27
02:21:34  47133.20    220.84
02:21:35  65734.86    348.91
02:21:36  43444.24    192.81
02:21:37  55281.62    260.41
02:21:38  70902.61    345.20
02:21:39  61351.06    298.33
02:21:40  56973.40    255.57
02:21:41  63535.54    314.64
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:21:42  62351.92    312.44
02:21:43  80183.78    482.16
02:21:44  35935.50    135.09
02:21:45  18757.51    121.89
02:21:46  10865.56     88.57
02:21:47   6301.87    116.73
02:21:48  59690.39    636.39
02:21:49  63399.55    348.95
02:21:50  48542.85    222.30
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:21:51  36881.65    212.34
02:21:52  62972.36    373.64
02:21:53  54096.12    264.91
02:21:54  58251.50    322.55
02:21:55  60595.40    275.94
02:21:56  22283.33    179.93
02:21:57  10404.02    148.78
02:21:58   5238.00    123.95
02:21:59   4034.98     80.90
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:22:00   3522.30     72.64
02:22:01   5469.38     50.20
02:22:02   7297.45     39.79
02:22:03   3099.11     54.25
02:22:04   3248.17     70.89
02:22:05   2913.00     71.76
02:22:06   2987.06     78.72
02:22:07  54645.86    255.73
02:22:08  61528.18    193.00
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:22:09  35396.66    202.57
02:22:10  19741.68    120.61
02:22:11  15428.63    115.48
02:22:12   7972.73     89.96
02:22:13   9824.29    126.01
02:22:14   4874.94    138.29
02:22:15   3796.94     96.80
02:22:16   3575.66     71.28
02:22:17   6495.05    138.44
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:22:18   9402.45    109.48
02:22:19   3968.94     58.29
02:22:20   3743.62     48.55
02:22:21   3694.58     91.52
02:22:22  39369.09    309.25
02:22:23  52195.56    270.83
02:22:24  65553.51    841.36
02:22:25  60596.64    308.53
02:22:26  49923.62    310.89
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:22:27  38015.93    272.27
02:22:28  77433.58    397.76
02:22:29  43295.96    177.89
02:22:30  39624.80    352.38
02:22:31  76940.18    313.48
02:22:32  48802.54    239.23
02:22:33  42220.54    210.28
02:22:34  30216.32    209.80
02:22:35  19857.96    168.15
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:22:36  19749.08    179.32
02:22:37  69007.84    383.16
02:22:38  62657.22    237.67
02:22:39  40278.10    182.12
02:22:40  29505.32     73.24
02:22:41  16779.58     80.06
02:22:42  13546.22     82.75
02:22:43  11332.97    115.06
02:22:44   9341.68    148.25
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:22:45   7892.18     99.29
02:22:46  63716.31    436.78
02:22:47  65213.64    228.96
02:22:48  37110.78    239.34
02:22:49  24108.09    138.60
02:22:50  20563.37    188.07
02:22:51  85426.18    519.25
02:22:52  60595.63    166.00
02:22:53  34772.03    147.21
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:22:54  20921.52    139.12
02:22:55  18048.99     91.69
02:22:56  14149.85    161.82
02:22:57  10498.95    165.25
02:22:58  45172.00    401.83
02:22:59  57405.60    189.23
02:23:00  23521.44    149.76
02:23:01  21669.55    189.22
02:23:02  16121.44    179.46
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:23:03  77328.84    420.89
02:23:04  41386.30    227.66
02:23:05  25465.56    172.06
02:23:06  17135.39    170.74
02:23:07   7251.74     99.70
02:23:08   7156.27    135.40
02:23:09   6012.16    100.57
02:23:10   7197.49     79.37
02:23:11  31121.92    308.29
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:23:12  49174.40    241.25
02:23:13  18126.57    193.59
02:23:14   8291.02     97.42
02:23:15   5704.04    130.39
02:23:16   5572.79     99.40
02:23:17   4238.67     51.94
02:23:18  23084.83    236.83
02:23:19  66062.94    301.79
02:23:20  69801.78    217.66
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:23:21  42275.56    190.32
02:23:22  33421.54    175.13
02:23:23  23242.02    237.03
02:23:24  74739.70    589.49
02:23:25  48575.43     89.82
02:23:26  22961.87    110.47
02:23:27  16669.12    150.61
02:23:28  19389.75    190.22
02:23:29  12441.76    148.14
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:23:30   9394.74     90.56
02:23:31   8814.92    107.57
02:23:32  10041.65    140.45
02:23:33   7615.92     81.05
02:23:34   4394.78     90.10
02:23:35   5058.33     97.70
02:23:36  17210.13    251.39
02:23:37  71479.65    599.75
02:23:38  36538.63    226.54
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:23:39  23137.74    204.80
02:23:40  13405.63    106.80
02:23:41  11146.87    141.70
02:23:42   8407.14    132.03
02:23:43   6475.33     99.52
02:23:44  10320.05     84.66
02:23:45   8336.83    130.87
02:23:46  48163.20    298.63
02:23:47  28930.53    163.72
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:23:48  13932.03    114.17
02:23:49  10571.42    109.56
02:23:50   9142.69    152.98
02:23:51   8345.02    104.82
02:23:52   5981.88     95.52
02:23:53   7646.74    144.23
02:23:54  63774.75    431.31
02:23:55  33982.19    128.44
02:23:56  11022.05     28.06
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:23:57  11703.95     80.05
02:23:58  22302.66    159.12
02:23:59  10086.63     89.38
02:24:00  14350.75     97.90
02:24:01  34534.08    415.80
02:24:02  57772.03    299.37
02:24:03  36504.87    174.28
02:24:04  21607.46    159.68
02:24:05  63727.13    305.43
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:24:06  41723.63    182.41
02:24:07  22508.25    120.39
02:24:08  36023.64    290.90
02:24:09  80853.44    276.29
02:24:10  68707.29    186.05
02:24:11  44681.10    103.14
02:24:12  30686.46    166.93
02:24:13  24367.32    166.80
02:24:14  23025.15    123.80
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:24:15  16374.40    161.83
02:24:16  13540.23    181.54
02:24:17  55362.17    535.15
02:24:18  71284.66    273.90
02:24:19  39006.55    190.18
02:24:20  29352.29    161.27
02:24:21  19205.08    126.50
02:24:22  13631.40     96.25
02:24:23  13984.01    146.13
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:24:24  11885.65    139.05
02:24:25  10765.22     89.47
02:24:26   9837.67    107.86
02:24:27   8067.06     99.33
02:24:28   7435.46    120.90
02:24:29   9676.53    164.67
02:24:30  11567.90    154.95
02:24:31   7071.66    139.11
02:24:32   7238.58    114.08
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:24:33   7380.01    135.64
02:24:34   9878.01    115.30
02:24:35   6907.94     89.99
02:24:36   5678.94    101.34
02:24:37   5108.99     78.75
02:24:38   5603.92     93.55
02:24:39  10047.05    168.08
02:24:40   6253.95     87.87
02:24:41   9258.91     99.51
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:24:42   5163.81     77.68
02:24:43   4742.32     76.61
02:24:44   4796.64     64.30
02:24:45   9213.41    152.15
02:24:46   5437.21     93.17
02:24:47   4815.19     53.38
02:24:48   4825.59     76.67
02:24:49   4778.73     98.66
02:24:50   8459.87    104.20
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:24:51   5823.31    112.63
02:24:52   6333.90     63.41
02:24:53   6218.70     73.32
02:24:54   4303.65     77.32
02:24:55   4034.35     63.10
02:24:56   8541.50    105.18
02:24:57  66760.80    496.00
02:24:58  72990.92    226.50
02:24:59  70738.14    226.90
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:25:00  48705.98    182.72
02:25:01  42352.30    195.52
02:25:02  35287.80    231.86
02:25:03  26577.77    196.54
02:25:04  26851.50    133.52
02:25:05  25732.53    211.39
02:25:06  50782.19    392.96
02:25:07  68746.20    183.96
02:25:08  40287.56    123.09
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:25:09  29495.92    148.00
02:25:10  17260.72    114.26
02:25:11  30780.41    242.87
02:25:12  88400.50    204.73
02:25:13  53483.17    137.77
02:25:14  28357.99     88.91
02:25:15  20691.74    120.55
02:25:16  19874.62    155.95
02:25:17  27575.89    273.08
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:25:18  87978.59    295.60
02:25:19  35152.23    112.75
02:25:20  22804.24    141.63
02:25:21  17659.70    131.40
02:25:22  17517.00    157.05
02:25:23  28606.48    219.29
02:25:24  12942.29    158.40
02:25:25  10937.27    111.85
02:25:26  10177.11    103.19
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:25:27  12103.97     79.12
02:25:28   9957.51     95.22
02:25:29   8232.01     98.03
02:25:30   9091.32     88.95
02:25:31   7223.65     83.58
02:25:32  12675.62    140.81
02:25:33  12580.18    147.82
02:25:34   6441.42     57.97
02:25:35   6371.36     79.69
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:25:36   4348.66     65.75
02:25:37   4983.48    125.04
02:25:38  92406.68    335.42
02:25:39  46378.26    138.67
02:25:40  29588.51    148.12
02:25:41  25718.35    164.80
02:25:42  19422.97    156.98
02:25:43  15440.77    214.03
02:25:44  73045.72    388.06
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:25:45  45430.09    159.06
02:25:46  30190.29     65.52
02:25:47  21028.20     56.76
02:25:48  14713.18    106.88
02:25:49  15327.04     93.09
02:25:50  14247.42     89.77
02:25:51  14259.28    155.16
02:25:52   9251.41    131.32
02:25:53  55407.45    346.64
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:25:54  65855.13    231.28
02:25:55  53515.27    286.13
02:25:56  74206.59    253.90
02:25:57  52763.92    175.76
02:25:58  41574.83    147.08
02:25:59  41699.50    158.14
02:26:00  31735.70    166.23
02:26:01  31175.74    206.41
02:26:02  42723.29    407.44
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:26:03  84512.22    337.51
02:26:04  54827.23    114.76
02:26:05  45921.46    164.45
02:26:06  31283.68    145.32
02:26:07  32760.08    165.74
02:26:08  31279.24    214.17
02:26:09  32475.31    239.85
02:26:10  89632.01    511.55
02:26:11  65139.50    197.75
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:26:12  45620.33    219.24
02:26:13  35992.47    181.68
02:26:14  20648.30     99.27
02:26:15  15937.25    110.60
02:26:16  88124.57    435.29
02:26:17  63627.90    170.19
02:26:18  42710.77    171.93
02:26:19  28587.40    153.24
02:26:20  19010.68    133.95
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:26:21  15239.48    108.86
02:26:22  22261.42    240.48
02:26:23  90092.43    536.38
02:26:24  49668.56    119.64
02:26:25  29174.26     52.31
02:26:26  25523.14    120.71
02:26:27  21444.93    113.81
02:26:28  19039.51    105.05
02:26:29  20322.35    149.35
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:26:30  16424.09    137.49
02:26:31  18055.73    194.58
02:26:32  93763.10    388.41
02:26:33  57006.67    199.86
02:26:34  38879.62    172.51
02:26:35  36929.73    148.98
02:26:36  20115.76    102.73
02:26:37  58781.17    467.04
02:26:38  81480.73    307.01
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:26:39  66074.77    185.19
02:26:40  59093.21    183.04
02:26:41  47310.03    121.97
02:26:42  51759.69    138.47
02:26:43  41423.16    113.82
02:26:44  37384.89    163.40
02:26:45  37392.45    159.13
02:26:46  26169.71    108.32
02:26:47  28784.15    195.75
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:26:48  17795.62    167.67
02:26:49  54385.83    358.89
02:26:50  71105.62    276.69
02:26:51  37402.86    153.60
02:26:52  31592.48    196.47
02:26:53  17890.61    140.24
02:26:54  16136.34    179.56
02:26:55  11446.82    120.61
02:26:56  14718.49    171.99
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:26:57  42355.41    249.34
02:26:58  86458.75    236.69
02:26:59  56783.69    155.03
02:27:00  40061.02    163.69
02:27:01  24649.42     91.67
02:27:02  23326.01    131.48
02:27:03  17044.87    133.29
02:27:04  14990.12    112.46
02:27:05  18407.80    184.32
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:27:06  51270.37    603.11
02:27:07  65746.89    276.98
02:27:08  48080.10    194.53
02:27:09  38869.17    170.04
02:27:10  27341.18    145.61
02:27:11  18631.65     92.26
02:27:12  37025.32    269.93
02:27:13  60984.46    214.34
02:27:14  44035.86    208.91
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:27:15  24763.50    160.09
02:27:16  13202.80    102.59
02:27:17  19576.65    204.94
02:27:19  81949.20    642.30
02:27:20  72806.61    240.26
02:27:21  64690.11    207.83
02:27:22  50213.85    109.43
02:27:23  41497.78    140.43
02:27:24  42515.89    209.17
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:27:25  42461.82    174.10
02:27:26  33700.94    168.96
02:27:27  32869.52    107.41
02:27:28  32631.54    178.13
02:27:29  32576.31    174.30
02:27:30  26762.37    183.74
02:27:31  57654.24    511.36
02:27:32  69653.15    204.22
02:27:33  61301.35    205.36
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:27:34  45061.74    151.23
02:27:35  35339.93    192.41
02:27:36  22439.62    146.83
02:27:37  15462.09     54.75
02:27:38  12528.15     35.61
02:27:39  12627.45     50.99
02:27:40  11996.36     69.41
02:27:41  13510.10    104.68
02:27:42  23204.21    198.36
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:27:43  15943.04    114.33
02:27:44  15076.80    118.37
02:27:45  10156.39    103.00
02:27:46  10422.15    135.71
02:27:47  12266.09    160.72
02:27:48  10922.82    145.37
02:27:49  12585.87    138.00
02:27:50  68289.63    352.15
02:27:51  60807.79    316.21
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:27:52  27762.34    188.39
02:27:53  20117.07    121.86
02:27:54  16655.50    115.44
02:27:55  13659.23     92.88
02:27:56  19868.94    160.38
02:27:57  11453.97     70.56
02:27:58  13390.40    140.28
02:27:59  13240.90    113.21
02:28:00  12676.01    130.32
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:28:01  46915.90    450.36
02:28:02  79553.08    654.74
02:28:03  60601.54    201.73
02:28:04  38376.10    187.34
02:28:05  30453.17    121.40
02:28:06  24634.53    168.62
02:28:07  20460.96    147.03
02:28:08  17133.40    130.35
02:28:09  14220.38    124.35
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:28:10  10983.89    102.29
02:28:11  27313.08    280.75
02:28:12  18886.11    178.06
02:28:13  11207.46     83.74
02:28:14  11177.55    117.12
02:28:15   5971.50     26.64
02:28:16   7536.95     87.90
02:28:17   7659.23    116.48
02:28:18  13167.34    157.62
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:28:19   8856.75    101.46
02:28:20  21839.90    249.04
02:28:21  21634.76    162.16
02:28:22   8565.96    103.46
02:28:23   7898.29     90.00
02:28:24   8704.44    101.95
02:28:25   7062.73     76.78
02:28:26   6465.20    124.62
02:28:27  17367.24    171.61
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:28:28  25245.66    196.62
02:28:29   8433.70     95.78
02:28:30  10175.92     52.76
02:28:31   8664.96    105.04
02:28:32   9006.16     95.31
02:28:33   5879.33     61.66
02:28:34   6918.05     65.44
02:28:35  10965.66    142.49
02:28:36  72947.28    739.04
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:28:37  73678.01    251.98
02:28:38  58886.80    166.31
02:28:39  32432.21    107.33
02:28:40  78547.68    381.96
02:28:41  67963.51    176.46
02:28:42  62552.06    148.66
02:28:43  55239.48    108.44
02:28:44  37857.05    112.51
02:28:45  34437.72    105.14
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:28:46  25011.91    104.95
02:28:47  17379.54     83.65
02:28:48  15233.39     91.98
02:28:49  13980.90     72.06
02:28:50  13755.29    109.45
02:28:51  12014.07     99.72
02:28:52  16094.17    115.84
02:28:53  13651.72     73.71
02:28:54  10630.23     75.37
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:28:55   7998.11     89.25
02:28:56   8803.32     56.79
02:28:57  57358.63    527.10
02:28:58  70942.49    256.42
02:28:59  63205.96    249.50
02:29:00  72486.67    262.17
02:29:01  63630.54    191.47
02:29:02  59942.47    146.56
02:29:03  44194.05    125.04
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:29:04  40216.38    132.22
02:29:05  33787.09    144.08
02:29:06  28827.74    132.45
02:29:07  60555.25    504.04
02:29:08  77544.44    414.35
02:29:09  66796.80    138.28
02:29:10  53373.66    142.60
02:29:11  42884.18    115.80
02:29:12  37071.29    137.86
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:29:13  28247.28    128.57
02:29:14  25520.22    132.26
02:29:15  24315.78    158.61
02:29:16  19461.36     83.62
02:29:17  19127.17    115.54
02:29:18  17749.41     95.44
02:29:19  19925.15    126.07
02:29:20  18659.55    104.82
02:29:21  14946.88     95.89
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:29:22  16163.44    132.98
02:29:23  16052.21     92.71
02:29:24  13242.81     92.66
02:29:25  14759.39    146.26
02:29:26  16566.62    192.35
02:29:27  15025.01    136.54
02:29:28  10528.31    104.79
02:29:29  10886.05    123.11
02:29:30   8513.08    122.78
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:29:31   8631.74     80.31
02:29:32   9103.51    144.35
02:29:33  14163.01    175.80
02:29:34  40962.72    493.84
02:29:35  93048.32    665.11
02:29:36  66424.20    261.16
02:29:37  59000.29    199.75
02:29:38  37862.25    117.94
02:29:39  36531.98    150.34
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:29:40  40262.95    147.31
02:29:41  30986.46    173.52
02:29:42  24124.62    163.99
02:29:43  18995.60    149.74
02:29:44  16674.01    154.58
02:29:45  19638.81    180.11
02:29:46  13889.63    129.72
02:29:47  12060.11    120.22
02:29:48  12496.54    148.26
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:29:49  14630.61    136.88
02:29:50  44890.28    339.14
02:29:51  80303.43    774.34
02:29:52  74545.47    283.52
02:29:53  65714.89    220.00
02:29:54  62666.76    173.67
02:29:55  62347.10    148.69
02:29:56  56790.12    140.29
02:29:57  61189.43    161.03
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:29:58  61268.59    133.26
02:29:59  52569.67    104.14
02:30:00  48180.98    117.89
02:30:01  45463.79    133.40
02:30:02  42118.19    175.73
02:30:03  33361.92    122.04
02:30:04  30977.12    153.76
02:30:05  26376.39    193.59
02:30:06  24151.89    140.94
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:30:07  27859.65    217.03
02:30:08  17074.16    141.67
02:30:09  17341.53     88.21
02:30:10  13711.81     66.33
02:30:11  14031.88    120.92
02:30:12  18071.87    127.80
02:30:13  10958.72     94.88
02:30:14  50175.89    403.47
02:30:15  22650.31    140.84
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:30:16  12285.94    103.64
02:30:17  15057.09    141.00
02:30:18  13864.30    124.51
02:30:19  14038.04    113.00
02:30:20   9788.40     85.55
02:30:21  14167.05     77.27
02:30:22   9607.41     84.15
02:30:23  11463.11     79.88
02:30:24   7735.19    101.06
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:30:25   9898.37    118.44
02:30:26   8772.24     95.22
02:30:27  13057.54    144.44
02:30:28   9840.82    108.84
02:30:29  15310.92    140.55
02:30:30  56621.52    481.95
02:30:31  19301.80    144.23
02:30:32  47218.27    584.58
02:30:33  66724.63    273.51
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:30:34  57402.13    180.79
02:30:35  53781.58    177.28
02:30:36  42859.96    148.14
02:30:37  25829.27    115.08
02:30:38  23305.98    164.23
02:30:39  23254.84    139.58
02:30:40  25676.02    176.34
02:30:41  14714.19    106.36
02:30:42  18272.70    147.78
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:30:43  10789.26     91.34
02:30:44  12355.84     83.97
02:30:45   8252.45     80.12
02:30:46  13603.73    157.97
02:30:47   8984.21    124.46
02:30:48  10610.11    118.70
02:30:49  49534.84    659.56
02:30:50  69002.60    406.49
02:30:51  55594.60    232.67
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:30:52  58367.57    263.09
02:30:53  51598.79    197.92
02:30:54  52928.29    257.74
02:30:55  66857.27    357.13
02:30:56  80847.42    463.30
02:30:57  49054.93    212.40
02:30:58  32558.85    167.15
02:30:59  19084.98     99.73
02:31:00  15713.44    101.56
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:31:01  17505.31    146.00
02:31:02  18007.33    183.57
02:31:03  21844.09    224.65
02:31:04  21458.43    202.42
02:31:05  20377.77    205.40
02:31:06  16818.59    138.02
02:31:07  17066.45    157.10
02:31:08  18720.30    202.31
02:31:09  51725.16    484.95
  Time           eth0       
HH:MM:SS   KB/s in  KB/s out
02:31:10  18991.26    150.26
02:31:11  10827.27    131.27
02:31:12   8537.31    106.34
02:31:13   8285.83    103.56
02:31:14  11360.60    162.70
02:31:15  74303.56    673.62
02:31:16  72552.23    288.89
02:31:17  65030.57    192.44
02:31:18  47718.31    153.97

It created a readonly data set that is compressible to less than 20GB and has 35GB of sig data in a separate directory. So the sig data can be deleted after it is verified, or with a bit more work, you can just skip it if you are willing to rely on checkpoint. then you can get a 20GB bandwidth used for a full sync (without sigs).

Still not fully optimized, but mostly processing at close to full resource utilization. I am not saying others havent done this too, all I am saying is that I have and maybe my experience is useful to some people who want to hear a different point of view than the party line.

v.129/129 (2000 1st.129) to 201 N[202] Q.70 h.402000 r.258000 c.0.000kb s.377583 d.129 E.129:452552 M.403286 L.403287 est.119 0.000kb 0:32:42 2.905 peers.83/256 Q.(0 0)

downloaded 377583 blocks, fully processed 258000 in 0:32:42

James

trashman43

full member

Activity: 298

Merit: 100

Quote from: jl777 on March 18, 2016, 07:08:27 PM

We could easily say SPV solves all signature attack problems. Just make it so your node doesnt do much at all and it avoids all these pesky problems, but the important issue to many people is what is the effect on full nodes. And by full, I mean a node that doesnt prune, relays, validates signatures and enables other nodes to do the bootstrapping.

Without that, doesnt bitcoin security model change to PoS level? I know how much you hate PoS

James

you paint the situation as if the binary options are 1. fully validating nodes (verify everything) and 2. thin clients (verify nothing). if we increase bandwidth pressure on nodes by increasing throughput capacity, then fully validating nodes can only switch to verifying nothing.

a much better solution is one that allows for fully validating nodes that would otherwise be forced off the network to partially validate -- whether by relaying blocks only, validating non-segwit tx, pruning data that is already under significant proof of work and therefore very likely secure. just because a pruned node cant bootstrap a new node doesnt mean it doesnt provide great value to the network.

are you suggesting that it would be better to simply force all these nodes off the network and into using trust-based protocols? because when you double bandwidth requirements and leave full nodes no other options, that's what happens.

there is a new term for this: "tradeoff denialism" Tongue

one could claim that increasing throughput doesnt mean pressuring nodes to shut down. but youd be living in denial, as throughput is directly related to bandwidth requirements

Topic: Segwit details? N + 2*numtxids + numvins > N, segwit uses more space than 2MB HF - page 6. (Read 21415 times)