|
JorgeStolfi
|
 |
March 18, 2016, 11:45:15 PM |
|
Absent the Schnorr sigs enabled by segwit, 2mb blocks would require "other general tweeks" in the form of restricting old style quadratic scaling sigs to some magic number maximum.
The initial depoyment of SegWit will not enable Schnorr signatures, will it? Won't they require a hard fork anyway? Even with Schnorr signatures, the miners would still have to accept old-style multisigs produced by old clients, right? Then an attacker could still generate those hard-to-validate blocks, no? As a temporary fix, a soft fork can be deployed limiting the max number of signatures. Even a low limit like 100 is no restriction, only a small annoyance for the few users who would want to use more It woudl be a good use of an "arbitrary numerical limit", like the 1 MB limit was when it was introduced. But there is no logical reason why signature validation should take quadratic time. That is a bug in the protocol, that should be fixed by changing the algorithm -- with a hard fork if need be. (By the way, [for a couple of hours today]( https://statoshi.info/dashboard/db/transactions?from=1458258715516&to=1458259562505) there was an apparent "stress test" where each transaction was 10 kB long (rather than the usual 0.5 kB). Was the "tester" trying to generate such troll blocks?) |
Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
iCEBREAKER
Legendary
 Offline
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
|
|
March 18, 2016, 11:54:10 PM |
|
Absent the Schnorr sigs enabled by segwit, 2mb blocks would require "other general tweeks" in the form of restricting old style quadratic scaling sigs to some magic number maximum.
The initial depoyment of SegWit will not enable Schnorr signatures, will it? Won't they require a hard fork anyway? Even with Schnorr signatures, the miners would still have to accept old-style multisigs produced by old clients, right? Then an attacker could still generate those hard-to-validate blocks, no? As a temporary fix, a soft fork can be deployed limiting the max number of signatures. Even a low limit like 100 is no restriction, only a small annoyance for the few users who would want to use more It woudl be a good use of an "arbitrary numerical limit", like the 1 MB limit was when it was introduced. But there is no logical reason why signature validation should take quadratic time. That is a bug in the protocol, that should be fixed by changing the algorithm -- with a hard fork if need be. (By the way, [for a couple of hours today]( https://statoshi.info/dashboard/db/transactions?from=1458258715516&to=1458259562505) there was an apparent "stress test" where each transaction was 10 kB long (rather than the usual 0.5 kB). Was the "tester" trying to generate such troll blocks?) Good questions. Let's try reading the fantastic manual: https://bitcoincore.org/en/2016/01/26/segwit-benefits/#linear-scaling-of-sighash-operationsLinear scaling of sighash operations
A major problem with simple approaches to increasing the Bitcoin blocksize is that for certain transactions, signature-hashing scales quadratically rather than linearly.
Linear versus quadratic
In essence, doubling the size of a transaction increases can double both the number of signature operations, and the amount of data that has to be hashed for each of those signatures to be verified. This has been seen in the wild, where an individual block required 25 seconds to validate, and maliciously designed transactions could take over 3 minutes.
Segwit resolves this by changing the calculation of the transaction hash for signatures so that each byte of a transaction only needs to be hashed at most twice. This provides the same functionality more efficiently, so that large transactions can still be generated without running into problems due to signature hashing, even if they are generated maliciously or much larger blocks (and therefore larger transactions) are supported.
Who benefits?
Removing the quadratic scaling of hashed data for verifying signatures makes increasing the block size safer. Doing that without also limiting transaction sizes allows Bitcoin to continue to support payments that go to or come from large groups, such as payments of mining rewards or crowdfunding services.
The modified hash only applies to signature operations initiated from witness data, so signature operations from the base block will continue to require lower limits. |
██████████
██████████████████
██████████████████████
██████████████████████████
████████████████████████████
██████████████████████████████
████████████████████████████████
████████████████████████████████
██████████████████████████████████
██████████████████████████████████
██████████████████████████████████
██████████████████████████████████
██████████████████████████████████
████████████████████████████████
██████████████
██████████████
████████████████████████████
██████████████████████████
██████████████████████
██████████████████
██████████
Monero
|
| "The difference between bad and well-developed digital cash will determine
whether we have a dictatorship or a real democracy." David Chaum 1996
"Fungibility provides privacy as a side effect." Adam Back 2014
|
| | |
|
|
|
jl777 (OP)
Legendary
Offline
Activity: 1176
Merit: 1132
|
|
March 19, 2016, 12:08:27 AM |
|
The modified hash only applies to signature operations initiated from witness data, so signature operations from the base block will continue to require lower limits. The way it is worded makes it sound fantastic... However, I couldnt find info about the the witness data immunities from the attacks. Are you saying that signature attacks are not possible inside the witness data? Clearly if signatures are moved from location A to location B, then saying signature attacks are not possible in location A. OK, that is good. but what about location B? Are sigs in the witness data immune from malicious tx via lots of sigs? It is strange this isnt specifically addressed. Maybe its just me and my low reading comprehension. But all the text on that segwit marketing page seems quite one sided and of the form: ### things are removed from the base blocks so now there are no problems with the base block, without addressing if the problems that used to be in the base block are actually solved, or just moved into the witness data. ### 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 |
|
|
|
|
trashman43
|
|
March 19, 2016, 12:52:50 AM |
|
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"  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 |
|
|
|
jl777 (OP)
Legendary
Offline
Activity: 1176
Merit: 1132
|
|
March 19, 2016, 01:52:06 AM |
|
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" 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: 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 |
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3388
Merit: 6631
Just writing some code
|
|
March 19, 2016, 02:50:20 AM |
|
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 (OP)
Legendary
Offline
Activity: 1176
Merit: 1132
|
|
March 19, 2016, 02:51:45 AM |
|
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 |
|
|
|
iCEBREAKER
Legendary
Offline
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
|
|
March 19, 2016, 03:05:52 AM |
|
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 |
██████████
██████████████████
██████████████████████
██████████████████████████
████████████████████████████
██████████████████████████████
████████████████████████████████
████████████████████████████████
██████████████████████████████████
██████████████████████████████████
██████████████████████████████████
██████████████████████████████████
██████████████████████████████████
████████████████████████████████
██████████████
██████████████
████████████████████████████
██████████████████████████
██████████████████████
██████████████████
██████████
Monero
|
| "The difference between bad and well-developed digital cash will determine
whether we have a dictatorship or a real democracy." David Chaum 1996
"Fungibility provides privacy as a side effect." Adam Back 2014
|
| | |
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
|
March 19, 2016, 08:09:37 AM
Last edit: March 19, 2016, 11:49:29 AM by molecular |
|
The following was quoted on and linked from reddit: 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? 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: 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? |
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3388
Merit: 6631
Just writing some code
|
|
March 19, 2016, 11:20:40 AM |
|
Is the following suggestion a solution to that? 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? Also, Tyler Nolan has a similar suggestion: 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
Legendary
Offline
Activity: 2772
Merit: 1019
|
|
March 19, 2016, 12:01:40 PM |
|
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: 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". 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? |
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3388
Merit: 6631
Just writing some code
|
|
March 19, 2016, 12:47:03 PM |
|
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". 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. |
|
|
|
TierNolan
Legendary
Offline
Activity: 1232
Merit: 1083
|
|
March 19, 2016, 07:33:53 PM |
|
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 2) hashing operation. The transactions could simply have been limited to 1MB. This would have meant no changes at all. The O(N 2) performance assumes that the block contains a single transaction. |
1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
|
|
|
jl777 (OP)
Legendary
Offline
Activity: 1176
Merit: 1132
|
|
March 19, 2016, 08:11:46 PM |
|
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 2) hashing operation. The transactions could simply have been limited to 1MB. This would have meant no changes at all. The O(N 2) 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? |
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
|
March 19, 2016, 09:16:06 PM |
|
With regards to the O(N2) hashing operation. The transactions could simply have been limited to 1MB. This would have meant no changes at all. The O(N2) 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. |
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
jl777 (OP)
Legendary
Offline
Activity: 1176
Merit: 1132
|
|
March 19, 2016, 09:21:19 PM |
|
With regards to the O(N2) hashing operation. The transactions could simply have been limited to 1MB. This would have meant no changes at all. The O(N2) 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 |
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3388
Merit: 6631
Just writing some code
|
|
March 19, 2016, 09:34:41 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. |
|
|
|
TierNolan
Legendary
Offline
Activity: 1232
Merit: 1083
|
|
March 19, 2016, 09:42:53 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. |
1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
|
|
|
jl777 (OP)
Legendary
Offline
Activity: 1176
Merit: 1132
|
|
March 19, 2016, 09:44:21 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 |
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3388
Merit: 6631
Just writing some code
|
|
March 19, 2016, 10:27:17 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. 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. |
|
|
|
|
