This is a tracking issue for RFC 35 - logging.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter.

Steps

Unresolved Questions

Implementation history

• #95

This is a tracking issue for RFC 41 - shutdown.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter.

Steps

Unresolved Questions

Implementation history

#97

Clippy currently reports false positives on the following issue rust-lang/rust-clippy#6447.
We are temporarily adding crate level #![allow(clippy::unit_arg)] until this is fixed.

This is a tracking issue for RFC 44 - secret-zeroize-drop.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter.

Steps

Unresolved Questions

Implementation history

#103

Bug description

Wrong type in nodeinfo response

Description

In the config, binding IP and port are sometimes configured as two key, sometimes as a single string.
Making the config more uniform would make the syntax easier to remember.

I would suggest the separate key option. Because that way you could use it as one liner.
Example:

mqtt = { address = "127.0.0.1", port = 1883, protocol = "tcp" }

which is the same as

[mqtt] 
address = "127.0.0.1"
port = 1883
protocol = "tcp"

Are you planning to do it yourself in a pull request?

Yes.

This is a tracking issue for RFC 37 - ternary-numeric-conversion.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter.

Steps

Unresolved Questions

Implementation history

• #94
• #108

This is a tracking issue for RFC 30 - protocol-messages.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter.

Steps

Unresolved Questions

Implementation history

This is a tracking issue for RFC 31 - configuration.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter.

Steps

Unresolved Questions

Implementation history

This is a tracking issue for RFC 36 - ternary.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter.

Steps

Unresolved Questions

Implementation history

• #82

This is the tracking issue for RFC 3 (bee-rfcs/#3), which adds the iri v1.8.1 transaction and bundle formats.

The RFC and hence this implementation is blocked by several features not yet being present. But the blockers were considered to be well encapsulated so that implementation can already begin before the other components are finished. The RFC accompanying this implementation and this implementation itself will be updated once its blockers land before being eventually merged.

Todo

• implement
• stabilize
• document

Unresolved questions

• Kerl sponge
• Curl-P sponge
• PearlDiver proof of work algorithm
• Winternitz One Time Signature scheme

• Tangle is a DAG representation of the underlying DB

Allows for:

• finding a transaction

• adding a transactions

• Add tests

• Trytes
• Trits
  • TE1
  • TE4
  • TE27
  • More?
• Utils?

This is a tracking issue for RFC 33 - network.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter.

Steps

• Merge the shutdown RFC
• Merge the shutdown code

Unresolved Questions

Implementation history

Here are possible crates or modules we need across many other projects? Please consider propose these RFC first.

This is a tracking issue for RFC 42 - secret-debug-display.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter.

Steps

Unresolved Questions

Implementation history

#101

pre-RFC #5

This is a tracking issue for RFC 34 - ternary-hash.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter.

Steps

Unresolved Questions

Implementation history

#102
#107
#109

The TransactionEssence currently is defined like this:

pub struct TransactionEssence {
    inputs: Box<[Input]>,
    outputs: Box<[Output]>,
    payload: Option<Payload>,
}

It allows to store every payload type. According to following RFC this shouldn't be possible.
A Transaction payload is only allowed to have an optional Indexation payload.

Bug description

Commit hash for the version doesn't update correctly with a simple cargo build

Bee version

• Bee version: ee429b7

Steps To reproduce the bug

• git pull
• cargo build --release
• target/release/bee -v

Expected behaviour

The last git commit hash should be updated with a simple cargo build

Actual behaviour

I need to do a cargo clean before cargo build to update the commit hash correctly.

This is a tracking issue for the open RFC “e3 protocol for bee” (iota-ledger/bee-rfcs#2).

This is a tracking issue for RFC 45 - api.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter.

Steps

Unresolved Questions

Implementation history

Description

Some channels need to be drained on shutdown, otherwise the data is lost and the database would be in a corrupted state.