server bracketing consistent with client
Jan 14, 8-9 PM (4)
Jan 14, 9-10 PM (4)
Jan 14, 10-11 PM (1)
Jan 14, 11-12 AM (6)
Wed
Jan 15, 12-1 AM (15)
Jan 15, 1-2 AM (3)
Jan 15, 2-3 AM (6)
Jan 15, 3-4 AM (9)
Jan 15, 4-5 AM (5)
Jan 15, 5-6 AM (3)
Jan 15, 6-7 AM (14)
Jan 15, 7-8 AM (5)
Jan 15, 8-9 AM (10)
Jan 15, 9-10 AM (10)
Jan 15, 10-11 AM (11)
Jan 15, 11-12 PM (11)
Jan 15, 12-1 PM (8)
Jan 15, 1-2 PM (12)
Jan 15, 2-3 PM (28)
Jan 15, 3-4 PM (19)
Jan 15, 4-5 PM (8)
Jan 15, 5-6 PM (2)
Jan 15, 6-7 PM (8)
Jan 15, 7-8 PM (13)
Jan 15, 8-9 PM (13)
Jan 15, 9-10 PM (7)
Jan 15, 10-11 PM (0)
Jan 15, 11-12 AM (4)
Thu
Jan 16, 12-1 AM (5)
Jan 16, 1-2 AM (4)
Jan 16, 2-3 AM (4)
Jan 16, 3-4 AM (7)
Jan 16, 4-5 AM (3)
Jan 16, 5-6 AM (9)
Jan 16, 6-7 AM (15)
Jan 16, 7-8 AM (16)
Jan 16, 8-9 AM (46)
Jan 16, 9-10 AM (6)
Jan 16, 10-11 AM (14)
Jan 16, 11-12 PM (18)
Jan 16, 12-1 PM (15)
Jan 16, 1-2 PM (12)
Jan 16, 2-3 PM (11)
Jan 16, 3-4 PM (25)
Jan 16, 4-5 PM (13)
Jan 16, 5-6 PM (25)
Jan 16, 6-7 PM (8)
Jan 16, 7-8 PM (16)
Jan 16, 8-9 PM (9)
Jan 16, 9-10 PM (3)
Jan 16, 10-11 PM (6)
Jan 16, 11-12 AM (4)
Fri
Jan 17, 12-1 AM (5)
Jan 17, 1-2 AM (6)
Jan 17, 2-3 AM (9)
Jan 17, 3-4 AM (10)
Jan 17, 4-5 AM (2)
Jan 17, 5-6 AM (8)
Jan 17, 6-7 AM (2)
Jan 17, 7-8 AM (3)
Jan 17, 8-9 AM (14)
Jan 17, 9-10 AM (24)
Jan 17, 10-11 AM (26)
Jan 17, 11-12 PM (27)
Jan 17, 12-1 PM (24)
Jan 17, 1-2 PM (18)
Jan 17, 2-3 PM (12)
Jan 17, 3-4 PM (15)
Jan 17, 4-5 PM (31)
Jan 17, 5-6 PM (14)
Jan 17, 6-7 PM (13)
Jan 17, 7-8 PM (13)
Jan 17, 8-9 PM (3)
Jan 17, 9-10 PM (5)
Jan 17, 10-11 PM (1)
Jan 17, 11-12 AM (1)
Sat
Jan 18, 12-1 AM (2)
Jan 18, 1-2 AM (0)
Jan 18, 2-3 AM (1)
Jan 18, 3-4 AM (0)
Jan 18, 4-5 AM (1)
Jan 18, 5-6 AM (0)
Jan 18, 6-7 AM (0)
Jan 18, 7-8 AM (0)
Jan 18, 8-9 AM (4)
Jan 18, 9-10 AM (4)
Jan 18, 10-11 AM (5)
Jan 18, 11-12 PM (0)
Jan 18, 12-1 PM (5)
Jan 18, 1-2 PM (3)
Jan 18, 2-3 PM (4)
Jan 18, 3-4 PM (7)
Jan 18, 4-5 PM (15)
Jan 18, 5-6 PM (1)
Jan 18, 6-7 PM (1)
Jan 18, 7-8 PM (0)
Jan 18, 8-9 PM (4)
Jan 18, 9-10 PM (0)
Jan 18, 10-11 PM (1)
Jan 18, 11-12 AM (2)
Sun
Jan 19, 12-1 AM (5)
Jan 19, 1-2 AM (0)
Jan 19, 2-3 AM (0)
Jan 19, 3-4 AM (0)
Jan 19, 4-5 AM (0)
Jan 19, 5-6 AM (0)
Jan 19, 6-7 AM (0)
Jan 19, 7-8 AM (1)
Jan 19, 8-9 AM (6)
Jan 19, 9-10 AM (0)
Jan 19, 10-11 AM (1)
Jan 19, 11-12 PM (1)
Jan 19, 12-1 PM (0)
Jan 19, 1-2 PM (0)
Jan 19, 2-3 PM (1)
Jan 19, 3-4 PM (2)
Jan 19, 4-5 PM (0)
Jan 19, 5-6 PM (1)
Jan 19, 6-7 PM (3)
Jan 19, 7-8 PM (7)
Jan 19, 8-9 PM (17)
Jan 19, 9-10 PM (1)
Jan 19, 10-11 PM (1)
Jan 19, 11-12 AM (0)
Mon
Jan 20, 12-1 AM (12)
Jan 20, 1-2 AM (1)
Jan 20, 2-3 AM (2)
Jan 20, 3-4 AM (5)
Jan 20, 4-5 AM (6)
Jan 20, 5-6 AM (4)
Jan 20, 6-7 AM (7)
Jan 20, 7-8 AM (6)
Jan 20, 8-9 AM (16)
Jan 20, 9-10 AM (11)
Jan 20, 10-11 AM (21)
Jan 20, 11-12 PM (10)
Jan 20, 12-1 PM (13)
Jan 20, 1-2 PM (22)
Jan 20, 2-3 PM (25)
Jan 20, 3-4 PM (15)
Jan 20, 4-5 PM (11)
Jan 20, 5-6 PM (10)
Jan 20, 6-7 PM (9)
Jan 20, 7-8 PM (3)
Jan 20, 8-9 PM (8)
Jan 20, 9-10 PM (6)
Jan 20, 10-11 PM (0)
Jan 20, 11-12 AM (5)
Tue
Jan 21, 12-1 AM (4)
Jan 21, 1-2 AM (0)
Jan 21, 2-3 AM (3)
Jan 21, 3-4 AM (2)
Jan 21, 4-5 AM (0)
Jan 21, 5-6 AM (0)
Jan 21, 6-7 AM (6)
Jan 21, 7-8 AM (9)
Jan 21, 8-9 AM (37)
Jan 21, 9-10 AM (10)
Jan 21, 10-11 AM (14)
Jan 21, 11-12 PM (17)
Jan 21, 12-1 PM (18)
Jan 21, 1-2 PM (27)
Jan 21, 2-3 PM (36)
Jan 21, 3-4 PM (15)
Jan 21, 4-5 PM (10)
Jan 21, 5-6 PM (8)
Jan 21, 6-7 PM (4)
Jan 21, 7-8 PM (3)
Jan 21, 8-9 PM (4)
1377 commits this week
Jan 14, 2020 -
Jan 21, 2020
[DDW-1149] - Implement acceptance tests for stake pools loading - fixes for scenarios
delete Ouroboros.Network.Server.Socket
node-to-{node, client} and diffusion refactor
Uses the Connections management system to get accept loops. Still TODO: make subscription workers use it too, for connections.
minor improvements to Connections iface
test-consensus: update Ref.RealPBFT for change to PBFT.exceedsThreshold
fix byron tests, now use mainnet data
Merge pull request #1729 from jmchapman/master
remove names from metatheory
[DDW-1149] - Implement acceptance tests for stake pools loading - fixes for scenarios
Merge branch ‘gh-pages-deploy’ into gh-pages
d188a5fcf73d26f51391c5aea5030dc8e152741d
Merge branch ‘gh-pages-deploy’ into gh-pages
d188a5fcf73d26f51391c5aea5030dc8e152741d
- Factor out ideation specific code from
Cardano.Ledger.Spec.STS.Update.Datato a new moduleCardano.Ledger.Spec.STS.Update.Ideation.Data - Generalize the
Ballotdata type and operations. - Finish implementing rules for votes.
Merge pull request #1288 from input-output-hk/anviking/WB-48/calculate-r-from-params
Calculate rewards from genesis parameters
fix cddl-test warnings for missing members
put all state into a unique directory, seperate from the main mainnet
also rename the binaries for launching daedalus, so you can have both installed at once
[DDW-1159] Merge latest v2-integration
[DDW-1184] Implement stake pool saturation and desirability attributes (#1826)
[DDW-1184] Adds saturation to stake pools Tooltip
[DDW-1184] Implement saturation UI
[DDW-1184] Handle no saturation
[DDW-1184] Update dummy stake data
[DDW-1184] Hide saturation bar on selected state
Merge #1288
1288: Calculate rewards from genesis parameters r=KtorZ a=Anviking
Issue Number
#1276
Overview
e2c8683848493634e8bcb13930b9e8e6bb6f5f5b [WIP] Calculate rewards from block0 params I am trying to keep the reward-calculation jörmungandr-specific. I don’t want to extend BlockChainParameters in core, since it would require DB-migrations (I’m pretty sure). Even so, the parameters /are/ jormungandr-specific, and should not belong in core.
79f53435242b07a2f877a3af1c63b6e290fbe05d Move to separate module + add Ratio type
2e2054344a09d22848f95ba9bea10942f0cc3cf5 add rankingEpochConstants function
b905f2cc028b852857e45beef023c0ca03ad5427 simplify and fix Jormungandr reward params extraction
3047095c57765b109979e6f4a67945c800f2d178 finish wiring up incentive parameters with jormungandr’s startup
e15f53a45d8bb0489a08ef7f91fe9021a76055af add simple unit test to compare ITN params with calculation
1c2fcb154b3df043f7ea218e35114e3839fe9cb8 fixup: typo in Ranking module
99dd776d5a99f8c066b59898ff2bed4f7353708f re-generate nix machinery
8ec5ef6586f02da59d0dd5e7d408b255c57491b4 additional test vectors for rewards calculation
905cb71807adc658d33bad90c991da42961e79ef make sure pools are sorted by apparent performance in scenario
2037c6049f72b2274f38d91915d310395bc9c690 use total block production instead of latest one The rationale is that it is quite confusing as many pools have only a few blocks produced per epoch (1 or 2) and sometimes even 0 for several epochs. This makes it even harder to assess whether a pool is doing okay or not. Looking at the total number of blocks produced makes more sense.
22fff45281556d3996f4d086cf7c0c2aa587439d add simple properties to test readTotalProduction
Comments
- I am trying to keep the reward-calculation jörmungandr-specific. I don’t want to extend BlockChainParameters in core, since it would require DB-migrations (I’m pretty sure). Even so, the parameters /are/ jormungandr-specific, and should not belong in core.
Co-authored-by: Johannes Lund [email protected] Co-authored-by: KtorZ [email protected]
[DDW-1184] Hide saturation bar on selected state
apply the bootstrapped blocks at a specific rate rather than every blocks
Merge pull request #1156 from input-output-hk/shelley/exec_spec/txsize_include_witnesses
Include witnesses in transaction size calculation
add simple properties to test readTotalProduction
add simple properties to test readTotalProduction
network: Restore peer map insert before connecting
In the other order, the subscription is reset.
Update iohk-nix
This is intended to fix buildkite/hydra timeouts
use total block production instead of latest one
The rationale is that it is quite confusing as many pools have only a few blocks produced per epoch (1 or 2) and sometimes even 0 for several epochs. This makes it even harder to assess whether a pool is doing okay or not. Looking at the total number of blocks produced makes more sense.
use total block production instead of latest one
The rationale is that it is quite confusing as many pools have only a few blocks produced per epoch (1 or 2) and sometimes even 0 for several epochs. This makes it even harder to assess whether a pool is doing okay or not. Looking at the total number of blocks produced makes more sense.
Merge #1288
1288: Calculate rewards from genesis parameters r=KtorZ a=Anviking
Issue Number
#1276
Overview
e2c8683848493634e8bcb13930b9e8e6bb6f5f5b [WIP] Calculate rewards from block0 params I am trying to keep the reward-calculation jörmungandr-specific. I don’t want to extend BlockChainParameters in core, since it would require DB-migrations (I’m pretty sure). Even so, the parameters /are/ jormungandr-specific, and should not belong in core.
79f53435242b07a2f877a3af1c63b6e290fbe05d Move to separate module + add Ratio type
2e2054344a09d22848f95ba9bea10942f0cc3cf5 add rankingEpochConstants function
b905f2cc028b852857e45beef023c0ca03ad5427 simplify and fix Jormungandr reward params extraction
3047095c57765b109979e6f4a67945c800f2d178 finish wiring up incentive parameters with jormungandr’s startup
e15f53a45d8bb0489a08ef7f91fe9021a76055af add simple unit test to compare ITN params with calculation
1c2fcb154b3df043f7ea218e35114e3839fe9cb8 fixup: typo in Ranking module
99dd776d5a99f8c066b59898ff2bed4f7353708f re-generate nix machinery
Comments
- I am trying to keep the reward-calculation jörmungandr-specific. I don’t want to extend BlockChainParameters in core, since it would require DB-migrations (I’m pretty sure). Even so, the parameters /are/ jormungandr-specific, and should not belong in core.
Co-authored-by: Johannes Lund [email protected] Co-authored-by: KtorZ [email protected]
make sure pools are sorted by apparent performance in scenario
make sure pools are sorted by apparent performance in scenario
Added routing for My Wallets page & walletSync comp.