Sia - Activity
Sia

A feed of development activity from across Sia Foundation GitHub repositories.

Jun 7, 2023
Jun 7, 2023
Jun 5, 2023

This PR adds an UploadManager that consolidates all uploads in a central manager, distributing both uploads and migrations (repairs) to uploaders in a way that we favour faster hosts and avoid hosts that are failing uploads for whatever reason.

It also adds a worker endpoint /worker/upload/stats that returns various upload statistics which helped during debugging and benchmarking. I've done a lot of benchmarking and tried various strategies, I don't think it's worthwhile going through everything I considered.

The baseline obviously varies from node to node, depending on your host set and various settings, but on my node the improved performance is just short of 3x, going from ~100mbps to ~300mbps for large uploads (160mb). On Chris his node however we're seeing a roughly 5x improvement so it really depends. Both our nodes can now upload at ~300mbps though.

Thanks to the new architecture we can also assert that a worker performs reasonably well with concurrent uploads. We've tried 2 and 3 upload threads and also single and multi-worker cluster setups. Going from 1-2 upload threads yields the same performance but going to 3 threads performance start to diminish slightly.

We'll probably keep on improving the upload performance over time, there's a bunch of strategies we can try now related to host selection and performance tracking, buffering reads (which we already do) and so on.

Jun 5, 2023

Turns out Association("Contracts").Replace and Association("Contracts").Append are going to recreate a contract after potentially deleting it. Causing inconsistent state in the db.

Jun 3, 2023
Jun 3, 2023
Jun 3, 2023
  • Fixed an issue where flat lines were not showing up on graphs.

  • Pricing metrics now show proper values.

Jun 2, 2023
Jun 2, 2023
  • Numbers are now displayed and entered in localized format.

    • https://github.com/SiaFoundation/web/issues/288

  • Currency options now include CAD, AUS, RUB, and CNY.

  • Dates and times are now displayed in a localized format.

    • https://github.com/SiaFoundation/web/issues/288

  • The wallet now shows a balance evolution graph.

  • The transaction details dialog title is now based on the specific type.

Jun 2, 2023
  • Numbers are now displayed and entered in localized format.

    • https://github.com/SiaFoundation/hostd/issues/56

  • Currency options now include CAD, AUS, RUB, and CNY.

    • https://github.com/SiaFoundation/hostd/issues/50

  • Dates and times are now displayed in a localized format.

    • https://github.com/SiaFoundation/hostd/issues/56

  • The volume creation dialog now allows selecting the location via text input.

    • https://github.com/SiaFoundation/hostd/issues/47

  • Pricing metrics are now in the same units as their corresponding configuration values.

    • https://github.com/SiaFoundation/hostd/issues/55

  • Contracts can now be sorted by expiration height.

    • https://github.com/SiaFoundation/hostd/issues/58

  • The metrics page now remembers selected data time span, interval, and date range.

    • https://github.com/SiaFoundation/hostd/issues/60

  • The Node overview now features a logs panel that shows the last 100 actions.

  • The transaction details dialog title is now based on the specific type.

  • Metrics now show the correct interval with start and end date time details.

    • https://github.com/SiaFoundation/hostd/issues/57

  • Updated to work with latest API changes

    • https://github.com/SiaFoundation/hostd/issues/53

Jun 2, 2023

https://github.com/SiaFoundation/hostd/issues/47

Jun 2, 2023

Adds alerts to the host. Initially these will be focused on background tasks, like volume management and contracts. It may be expanded in the future.

Adds [GET] /alerts and [DELETE] /alerts endpoints

Changes add, resize, and delete volume actions to complete asynchronously. The blocking portion will return an initial error for permission errors, but background errors, like during migration, will be surfaced through alerts/log messages. An optional channel argument has been added to each function to signal completion.

Jun 2, 2023

Closes https://github.com/SiaFoundation/renterd/issues/379

Jun 2, 2023

Still benchmarking, code is nowhere near ready for review yet. Just a quick test to see how much improvement we'd get from refactoring uploads into a queue.

edit: got some preliminary results:

BASELINE:

1 thread:
...
upload finished in 6.681s (150.66 mbps)
upload finished in 8.695s (115.77 mbps)
upload finished in 10.615s (94.84 mbps)
average upload speed 111.788 mbps

4 threads:
...
upload finished in 9.863s (102.06 mbps)
upload finished in 9s (111.85 mbps)
upload finished in 29.04s (34.66 mbps)
average upload speed 80.5925 mbps

UPLOAD QUEUE:

1 thread:
...
upload finished in 3.412s (294.99 mbps)
upload finished in 4.254s (236.64 mbps)
upload finished in 3.092s (325.59 mbps)
average upload speed 231.88519999999997 mbps

4 thread:
...
upload finished in 12.699s (79.27 mbps)
upload finished in 11.095s (90.73 mbps)
upload finished in 4.762s (211.38 mbps)
average upload speed 147.0347 mbps

this is without tracing or really digging deep so definitely room for improvement, especially considering multi-threaded benchmarks are now slower than single threaded. Would like to get close to 1gbps but let's see.

Jun 2, 2023

The revision mismatch is caused due to an issue in siad which will be fixed in hostd. Until then, this change will serve as a workaround.

NOTE: The "proof verification failed" - error is a side-effect of the revision number mismatch. So it's also fixed by this PR.

Jun 2, 2023

As the title suggests we should abort scanning as soon as one scan fails since that should never be the case to begin with. The autopilot will then retry in the next iteration.

We also shouldn't scan if we don't consider ourselves as online.

Jun 2, 2023
Jun 2, 2023

This fixes the failing workflows.

Jun 1, 2023

Closes #64

Jun 1, 2023

https://github.com/SiaFoundation/hostd/issues/57 https://github.com/SiaFoundation/hostd/issues/58 https://github.com/SiaFoundation/hostd/issues/60

May 31, 2023
May 31, 2023
  • https://github.com/SiaFoundation/hostd/issues/53

  • https://github.com/SiaFoundation/hostd/issues/50

  • https://github.com/SiaFoundation/hostd/issues/55

  • https://github.com/SiaFoundation/hostd/issues/56

May 31, 2023
May 30, 2023

hostKey is passed to PrepareContractRenewal, although it is not used there.

May 30, 2023
May 30, 2023

Closes https://github.com/SiaFoundation/renterd/issues/378

May 30, 2023

Fixes failing syncs in case the account is completely drained.

May 30, 2023
May 30, 2023

After renewing a contract we weren't adding the host transaction to the txnSet. So broadcasting it would always fail. This PR fixes that.

May 30, 2023

That way, bootstrapping from an existing consensus set won't feel like renterd is hanging and instead the API will launch immediately like it does when starting from a fresh consensus set. The scan progress can then be polled through the API.

Closes https://github.com/SiaFoundation/renterd/issues/380

May 30, 2023
May 29, 2023
May 26, 2023

This PR changes the /metrics/:interval endpoint to calculate the number of periods between start and now when periods is unset. This enables easily getting YTD statistics without additional scripting.

May 26, 2023
May 25, 2023

To avoid accidentally dialing localhost in case the port is set but the address isn't.

May 24, 2023

To avoid accidentally nuking your contract set when your machine is on sleep or the VM you run renterd in is suspended, this PR adds the last block's timestamp to the consensus state.

If more than 60 minutes (6 block times) have passed since the latest block, we only check that the host is at least on the same block height as we are since we may no longer be synced.

Closes https://github.com/SiaFoundation/renterd/issues/367

May 23, 2023
May 23, 2023

This PR adds a new PUT /objects endpoint on the worker for uploading data. The difference to the existing endpoint is that instead of providing the object path as a path param, the uploaded data is prefixed with a json object that contains a list of paths and lengths which the uploaded data is then sliced to.

The main purpose of this endpoint is to package small files together to reduce wasted storage space. e.g. 1000 40kib files can be uploaded as a single 40 MiB slab that is referenced by 1000 objects. Instead of uploading 1000 slabs.

May 23, 2023
May 23, 2023

This PR migrates the wallet persistence over to the SQL db, extending the existing consensus info table, adding 2 more tables for transactions and outputs as well as integrating the persistence into the buffered applyUpdates.

Since I was already at it I made sure to create outputs in the db for delayed outputs as well.

Closes https://github.com/SiaFoundation/renterd/issues/255

May 22, 2023

Since v3 hosts don't require any cleanup, this PR refactors withHostV3 to newHostV3 to reduce overall nesting and decrease the likelihood of mistakes happening due to the increased usage of named variables.

May 22, 2023

Whenever we record contract spending, we also record the new revision number.

That revision number might temporarily diverge from the actual one in rare cases (e.g. crash before recording) but it's a good reference value.

May 20, 2023
  • The copy authenticated URL toast is now properly formatted.

May 20, 2023
  • Directory navigation in the volume creation dialog now works properly when navigating up to the root drive.

  • Metrics charts now properly show the final data point.

  • New directories can now be created directly from the volume creation dialog directory selection tool.

  • Dynamic DNS configuration errors are now displayed in full.

  • Price settings are no longer described as "minimum".

  • Host announcement transactions now show up labeled as such in the transaction list.

May 20, 2023
May 19, 2023
May 19, 2023

This PR fixes an issue where gouging checks fail after a while since we never update the consensus state within the gouging checker. So instead of attaching a gouging checker to the context, we attach a function to create a gouging checker on demand.

While going through the code to see what calls to update, I ended up doing a few refactors as well. Mostly to achieve the following structure for all endpoints calling RPCs.

  1. The RPC is a function (not a method) located in rhpv3.go

  2. The RPC is called by an exposed method on the host type.

  3. The method on the host is called by a method on the worker that has the same name but essentially only calls withHost.

There might be a few leftovers that also require updating but I think this really improves the overall readability since it is strictly endpoint calls worker calls host which performs RPC and not some mix.

May 18, 2023

hostd@0.11.0

  • Volumes view and create now available from the command palette.

  • Contract total usage sum now no longer includes risked collateral.

  • Contract timelines and other features based on block height now use estimated block height for current height until synced.

  • Core features are now immediately accessible without waiting for blockchain sync to complete.

  • Hovering over the Sia logo now triggers a popover that shows daemon info and sync status.

  • The displayed wallet balance is now spendable+unconfirmed.

  • The volume delete dialog now resets when it is closed.

  • Risked collateral is now next to locked collateral in the contracts table.

hostd@0.10.0

  • Create and resize volume features now support Windows file paths.

  • Dynamic DNS configuration now supports the required provider specific options.

  • Wallet send siacoin feature now correctly reports successful transactions.

  • The configuration RHP3 section is now called Accounts.

  • Contracts explorer payout column values are now accurate.

  • The create volume directory selection now reports the correct free space.

  • Configuration tabs now include more specific validation errors and feedback.

  • Wallet transaction list now shows siacoin value for pending transactions.

  • Dynamic DNS now supports cloudflare.

  • Broadcasting host announcement now requires confirmation and shows the siacoin transaction cost.

  • Configuration no longer includes a window size setting.

May 18, 2023
May 18, 2023
May 17, 2023
May 16, 2023
  • Deleting a file now requires confirmation.

  • Configuration tabs now include more specific validation errors and feedback.

  • Configuration now shows average network prices based off Sia Central data.

  • The contracts feature has been updated to use the new endpoint.

May 16, 2023
May 16, 2023
May 12, 2023
May 11, 2023
May 10, 2023
May 5, 2023
May 5, 2023
// MarshalText implements encoding.TextMarshaler.
func (uk UnlockKey) MarshalText() ([]byte, error) {
	return marshalHex(uk.Algorithm.String(), uk.Key[:])
}

Causes UnlockKey to JSON encode as "\"ed25519\":48a468d62e48e27ef24707bd1f467476e9605954e201834c659e614b9704d041"

This will likely break a bunch of things in hostd and renterd. Is adding compatibility code for this in core worth it?

May 5, 2023
May 2, 2023
May 2, 2023
  • Significantly improves performance of the metrics endpoint when dealing with many periods.

  • Changes usage from /api/metrics/monthly?start=2023-01-01T00:00:00-06:00&end=2024-01-01T00:00:00-06:00 to /api/metrics/monthly?start=2023-01-01T00:00:00-06:00&periods=12

May 2, 2023

I noticed the account settings aren't set when converting from the new settings object to the old rhpv2 settings.

May 1, 2023
Apr 28, 2023
Apr 28, 2023

This PR adds the InitProgramHelper which makes it a bit nicer to compute costs for programs.

e.g. computing the cost of a read sector program becomes this

rc := pt.InitProgramCost()
rc.Add(pt.ReadSectorCost(rhpv2.SectorSize))
cost, _ := rc.Total()

where previously we couldn't make use of the ResourceCost type for the base cost.

Also snuck in a receiver change that Nate proposed.

Apr 28, 2023

This PR adds PriceTableValidity to the host settings, making it configurable so we can lower it in testing. I have also increased the default validity from 10 to 30 minutes. Maybe we can increase it even further but I don't think that's worth it.

Apr 26, 2023
Apr 25, 2023
Apr 20, 2023

This should prevent an overflow panic when the hosts set their prices ridiculously high. Could fix renterd/#283

Apr 18, 2023
Apr 18, 2023

This came up in a renterd review the other day so I decided to propose it. I'm still not sure whether it's silly or actually useful so I figured I would let you be the judge Luke. Definitely feel free to just close this out, I was expecting way more occurrences to be honest, was surprised to only find a handful.

Apr 18, 2023

This PR adds a Name field to the Network object in the consensus package. By adding the network name the UI can differentiate between the mainnet and the testnet and adjust accordingly.

Apr 13, 2023

Turns out if you have a MarshalText method, you don't need MarshalJSON too. So that's nice.

I still want to write a JSON encoder at some point; it would be really nice if we could autogenerate fast encode/decode functions, with options like useCamelCase and noNullSlices -- but for now, struct tags will have to do.

Apr 13, 2023

ok, I did something kinda weird here: I implemented a txpool, but I did it inside the chain manager.

This requires some justification. The "normal" way to implement the txpool would be as a subscriber to the chain manager. This is how it's done in siad: modules.TransactionPool subscribes to modules.ConsensusSet. The pool receives transactions from the user (and from peers), and when a block comes in, it removes any confirmed transactions from the pool. Simple, right? This is the approach I initially used for core as well.

Once I had finished prototyping and started hooking everything up, though, I ran into some difficulties. I came up with workarounds, but something still felt off. The final straw came when, after implementing (what I thought was) the final workaround, I realized that I had introduced a deadlock. It was time to take a larger step back.

The source of the trouble was transaction validation. The txpool has to ensure that all of the transactions in the pool could potentially be included in the next block. So when a new block is mined, all of the transactions in the pool have to be revalidated against the new state. Transactions in the pool may also depend on each other, so invalidating one transaction could cascade to many more. Separately, validation also has to occur when new transactions are added to the pool. (These requirements are what led me to implementing #107) But here's the problem: validating transactions requires access to the consensus database. This creates a dangerous cycle: the consensus database is owned by the chain manager, so the txpool needs to call into the chain manager to validate new transactions; but the txpool is also subscribed to the chain manager, so the chain manager needs to call into the txpool to give it new blocks. The situation is ripe for a deadlock.

siad solves this problem by having the txpool call a special method on the chain manager: LockedTryTransactionSet. This is a function that takes a function that takes a transaction validation function and calls it while holding the chain manager mutex, so that the second function can call the validation function arbitrarily while protected by the lock. Simple, right? 🙃 (I was, um, not particularly happy with this solution, and expressed as much in the commit message and branch name.)

I think I must have repressed the memory of writing that code, because otherwise I wouldn't have plowed ahead with the same exact architecture in core. It was only when things failed to come together nicely that I remembered what had transpired years ago...

ppf-lol

Anyway, when you have two components that are all mixed up in each other's biz, there's really only one solution: smash them together into one big component. Usually this feels wrong; my gut insists that the chain manager and txpool are "different things" that shouldn't live under one roof, and there's a way to cleanly separate them if I try hard enough. But hey, sometimes your gut is wrong. After all, the deadlock is gone now -- can't argue with that.

Interestingly, this problem entirely disappears in Utreexo. There's no more consensus database, so the txpool no longer needs to access it through the chain manager; instead, it can maintain its own copy of the full consensus state (updated via subscription), and validate all transactions against that -- nice! So once we migrate to Utreexo, it should be possible to split these two components apart again. But who knows, there may be other reasons to keep them together that aren't clear yet. Time will tell.

Oh, one more tidbit: the new txpool is lazy. Rather than revalidating the pool after every block, it only does so when necessary, e.g. when someone calls PoolTransactions. A similar principle is applied to the RecommendedFee and UnconfirmedParents methods. In steady-state, this probably doesn't make a big difference in performance (since the UI will poll more than once per 10 minutes), but when you're syncing thousands of blocks, it absolutely does!

Apr 8, 2023

This is an unfortunately-messy diff, but the gist is that consensus now has a MidState type that tracks the state of the blockchain within a block.

When we verify or apply a transaction, we do so relative to the prior block's state and the effects of all previous transactions in the current block. For example, if transaction 0 spends an input, we don't want to allow transaction 1 to spend it too, even though both spends are valid in the context of just the prior block's state.

siad handles this by directly applying the effects of each transaction to its consensus.db, rolling back if an error is encountered. But in core, we want to cleanly separate validation from application; the Validate functions do not have write-access to the consensus database. Thus, any tracking of mid-block effects has to be handled in memory. Previously, this was done on an ad-hoc basis. For example, validateSiacoins iterated over a list of transactions, inserting the relevant parent IDs into a map[types.SiacoinOutputID]int, while validateContracts performed a similar operation with a map[types.FileContractID]types.FileContract. The new MidState type essentially collects all of these maps into one place, so that the validation functions can focus on, well, validation, rather than updating state. This also results in some nice unification of code that was duplicated across the validate functions and ApplyDiff.

The actual motivation for this change, however, came from the txpool. Part of the txpool's job is to produce a list of transactions that could potentially form a block; therefore, it naturally needs to do the same sort of mid-state validation/application as consensus. Furthermore, for efficiency, we really want to store this mid-state somehow, rather than having to recompute it every time a new transaction is submitted to the txpool. It all seems obvious in retrospect, but I had to stumble through a few different approaches to this problem before finally identifying "mid-state" as the unifying concept. :)

I have re-synced a core node with these changes and it validated to tip without any problems, so I'm pretty confident in its correctness. That said, we'll want to do a final pass on all consensus code before deploying anything on mainnet.

Apr 5, 2023

Right now RPCRenewSignatures doesn't match RPCRenewContractRenterSignatures and RPCRenewContractHostSignatures from siad. So rhpv3 renewals fail due to a decoding error.

Apr 4, 2023

Adds the same helpers we already have for rhpv2 but slightly updated for rhpv3.

NOTE: taxAdjustedPayout is a copy-paste and exactly the same for rhpv2. Feel free to suggest a better place for it or to push a commit that moves it.

Apr 4, 2023
Apr 4, 2023
Mar 29, 2023
Mar 27, 2023

This PR includes:

  • Modification that will help container build consistency

  • Updated container image labels

  • Updates to documentation

Mar 27, 2023

Updated processPayment to use the height specified in the pricetable as the host's current height.

I noticed various NDFs due to hostd and renterd not agreeing on the height they use for certain things like payment receipts. This PR fixes those.

This will also be important for things like the rhpv3 upload RPC where the block height is used to determine storage cost and collateral.

Mar 24, 2023
Mar 24, 2023
Mar 24, 2023
Mar 23, 2023
Mar 21, 2023
Mar 21, 2023

Adding the types for the request and response of the RPCLatestRevision RPC to use in renterd.

Mar 20, 2023

This adds support for the Sia gateway protocol. core nodes will identify themselves as version 1.5.5, so that we can distinguish between core nodes and siad nodes. (This will be important for mainnet testing.)

Mar 12, 2023

Add tests that cover most of the contract creation/revision related code in consensus/validation.go and a case for a block that exceeds the maximum weight.

Mar 8, 2023

Add consensus tests like some of the ones we have in v2. Test cases for file contracts coming shortly.

Mar 4, 2023

Flip-flopping on #96 :|

I don't like build tags in general, but I'll allow it for this. It's better than branching through s.params() everywhere.

For posterity, I also investigated a "fork flag" approach, which worked like this:

type ForkFlags uint64

const (
	ForkTestnet ForkFlags = iota
	ForkDevAddr
	ForkTax
	// ...
)

type State struct {
	ForkFlags ForkFlags
	// ...
}

// used like so:
func (s State) NonceFactor() uint64 {
	if s.ForkFlags&(1<<ForkASIC) != 0 {
		return 1009
	}
	return 1
}

// set like so:

type Network interface {
	ForkFlags(s State, b types.Block) ForkFlags
}

func ApplyState(s State, store Store, b types.Block, network Network) State {
	// ...
	return State{
		ForkFlags: network.ForkFlags(s, b),
	}

Basically, you pass a Network to ApplyState, and it sets the fork flags on the resulting State. So on mainnet (and testnet), we would pass a Network that sets flags based on s.Index.Height. In our automated tests, though, we could set the flags directly, instead of fast-forwarding to a particular height like we do now. Neat! Another cute feature is that you can encode the flags as a string, with emoji representing each flag.

Unfortunately, practice turned out to be uglier than theory. This approach could work, but it would require many more flags than you would expect. For example, the Foundation subsidy is paid out every 4380 blocks, starting at the hardfork height. But in this design, State doesn't know what the hardfork height is. So instead, we have to define a separate ForkFoundationSubsidy flag, and make Network responsible for setting that flag at the appropriate heights. Oh, but you also need a ForkFoundationInitialSubsidy, which is set exactly once, on the hardfork activation block itself! Similarly, you need two or three distinct flags for the ASIC hardfork, because there are specific actions that must occur on the activation block and on the block immediately prior to activation.

Like I said... it could work, but it forces you to move what feels like consensus code (e.g. Foundation subsidies) outside of the consensus package, which makes me uncomfortable. I got about halfway through the implementation before it started feeling so messy that I just got sad and scrapped it all. If I were implementing a new blockchain, I might take this approach, but it just doesn't work very well for the blockchain we have. :/

Mar 4, 2023

Take number 3 of #96 🙃

In this approach, we add the network parameters as a field of State, but do not encode them. Mainnet and Testnet are defined in chain, keeping consensus pure.

I think I prefer this to #97; having a Network struct feels like the right abstraction, and this approach doesn't require hardcoding mainnet/testnet stuff into consensus.

Feb 28, 2023

I took a stab at addressing the issue that I alluded to in https://github.com/SiaFoundation/core/pull/95. The approach I ended up taking was a bit different than what I originally suggested. The problem with embedding the entire NetworkParams struct within State is that now you have to encode/decode all of those parameters every time you encode/decode a State. This is egregiously wasteful; the consensus DB would end up storing hundreds of thousands of copies of the same parameters. I suppose we could have the DB override the encoding of State, but you'd also have to override the encoding of any type that contains State (e.g. Checkpoint), and this would affect all future users of State, not just us.

It occurred to me that we could store just an ID, rather than the full params, and use the ID to select from a set of parameters defined locally in consensus. Then I thought: why bother with the IDs at all, when we can already distinguish between mainnet and testnet using (State).GenesisTimestamp? So that's what this PR does: use the genesis timestamp to select the set of network parameters.

I don't love this approach; it feels "sneaky," in the same way that global variables are sneaky. In particular, I don't like defining mainnet vs. testnet parameters within consensus itself. But the alternative -- passing them in -- means that they have to be embedded in every State object (wasteful/cumbersome) or supplied as a separate argument (i.e. everywhere we pass consensus.State, we now also have to pass a NetworkParams... gross). I also don't see much practical use for passing a NetworkParams other than mainnet or testnet.

That reminds me: another thing to note here is that we've gone from "standard, dev, testing, testnet" to just "mainnet, testnet." I don't think we have any real use for dev and testing anymore. dev was for antfarm stuff (which we can/should do on testnet now). testing was mostly a way of lowering the difficulty so that we could mine long chains during automated testing -- but if you set a very low initial difficulty, you can mine a lot of blocks before the difficulty ramps up. testing also triggered hardforks much earlier, but that's true of testnet as well, and the new consensus design makes it trivial to "fast-forward" to any desired hardfork height anyway.

Mainnet and testnet share a lot of constants (e.g. BlockInterval), so I didn't bother moving all of them to networkParams. You could argue that they belong there anyway, but idk, I'd rather have networkParams only specify what actually differs between chains.

cc @n8maninger

Feb 27, 2023

Temporarily adds testnet consts to rhp/v2 for the tax hardfork. Enables testnet builds in hostd and renterd

Feb 27, 2023

This PR fixes some of the encoding issues in the new rhp code. I've only tested it with ReadSector. I decided to open a PR because I think Nate and I are working through the same issues so I figured we could consolidate our efforts into one PR/branch and get it merged.

The main issues I think are:

  • [ ] instructions should be length prefixed

  • [ ] writeObject requires a hack-fix in the lenght prefix because MDM programs now include the data

  • [ ] order of field encoding is off at times

  • [ ] some fields are missing in the encoding

Feb 24, 2023
Feb 23, 2023

We need a ForceClose that doesn't try to gracefully close the transport by writing LoopExit. The reason for this is that the transport reuses bytes on write causing a data race if we try to close the transport from another thread.

Feb 23, 2023

My node crashed due to an overflow in a Mul call so I extended core to allow for handling that. I also thought it might be useful to have MaxCurrency. e.g. if multiplying storage and collateral results in an overflow, we could use MaxCurrency as the intermediary result for scoring instead of aborting.

Feb 22, 2023
Feb 3, 2023

See https://github.com/SiaFoundation/core/pull/79 and https://github.com/SiaFoundation/renterd/pull/126.

There are a few warts that will need to be cleaned up eventually, but this is good enough to build on.