givelotus / lotusd Goto Github PK

Need to update diskmagic before launch.

Currently, the node limits transaction chains to a maximum of 25 unconfirmed transactions long. This poses a problem to a number of wallets and other services which need to send and receive coins frequently. As such, this limit should be removed. Unfortunately, the existing software's package handling algorithms are n^2, which would leave open a DoS vector if this limit was removed.

This issue represents all the necessary work to the mining and mempool to remove the limit.

• Start with an empty chain
• Run getblocktemplate

This needs to be addressed somehow

As per title. We don't want to engage in soft fork upgrades for these sorts of things. We should ban them completely before launch.

We don't want to be BSV, but we also want people to innovate. The current limit of just one OP_RETURN output per tx is often seen as very restrictive.

Currently, many protocols use one entire OP_RETURN for payload, following the Lokad ID spec: https://upgradespecs.bitcoincashnode.org/op_return-prefix-guideline/

However, these protocols can interact with each other. Hence, it is useful to be able to use multiple of them.

If we raise the limit of OP_RETURNs to 3, the maximum payload per tx is 660, which is just 140 bytes longer than a single max. push in a scriptSig, so there doesn't seem to be much harm. Theoretically, users could put 1650 bytes per scriptSig.

Right now, it's possible to create coinbase txs that have the same hash as txs on Bitcoin Cash, as long as their mined height matches.

This can create quite subtle attack vectors, e.g. creating a tx on Logos thats valid on both chains, sending coins to the victim and then letting them sign a tx that's also valid on BCH, but for higher amounts.

One way to fix this is to pick an additional prefix (prepended to the height) for the coinbase that:

1. Can't be a height
2. and that also occurs in no historic coinbases

For this, we should do the following:

1. Collect all coinbase hex strings
2. Find prefixes that none of the coinbases have and that also isn't a valid height
3. Enforce that prefix on all coinbases

New blockheader as defined here: https://github.com/EyeOfPython/specifications/blob/neko-spec/neko/SPECIFICATION.md

They are non-standard, but can be in blocks. This makes a new tx format really hard to implement.

This test has been disabled since there's no testnet with valid checkpoints.

It should be re-enabled after once there is.

The issuance of Coinbase rewards will be changed to be a fixed 1 gigasat (10^9 sats) in perpetuity. 262800 gigasats will be issued per year.

Half will go to miners
Half will go to servicing the blockchain and users
    25% of is will go to node development
    25% of this will go to wallet development
    25% of this will go to education
    25% of this will go to user wellbeing

Half of fees will be burned, the other half will go to miners as a fee for including transactions.

Implement OP_MULPOW2 that will be explicitly 64 bit unless there's an opt-in flag at a later date to larger numbers. It will fail on overflow. Underflow will drop the bits. This is equivalent to arithmetic shifting.

Currently the node logs using a custom format for every piece of data (minus the timestamp data). This requires a fluentd setup and custom regexs to do basic analytics on the result. Instead we should make the daemon output structured logs natively. Preferrably this would be done using JSON logging.

This will enable logs to be collected and analyzed more easily when doing performance checks.

Because of fee burns, and the possibility of introducing a PoW based coin stability mechanism in the future, we should track the number reward per block in the block index. This will enable a future hardfork which depends on these values to not require data migrations.

As per title. We don't want to use bitcoind datadir.

There’s no point in keeping non-standardness as default.

Currently, Bitcoin is limited to 32 bit signed integers. This is due to overflow checks. However, having 64 bit signed integers would open up the possibility of doing a lot more interesting things on the blockchain. We should handle overflows using builtin functions so we can detect them, and invalidate the transactions. If we do this, we can move to 64 bit integers.

Backporting a modified version of Taproot (BIP341) would give us a bunch of advantages:

• MAST, which allows representing scripts with a lot of IFs in a much more efficient and private way.
  • This also on some level increases the opcode limit by a factor of 2^128, which is the number of possible leaves. With proper CashScript support, this would make writing smart contracts a lot easier, as developers don't have to check whether their script broke the limit as much.
• Spending P2SH-esque outputs without revealing the script, adding privacy for complex scripts, especially useful for those involved in business banned in some countries, e.g. gambling.
• Advanced txs insight through a new sighash algorithm, allowing introspecting the amounts and scriptPubKeys of other inputs.
  • Also allows much more efficient introspection as parts of the serialization are simply left out if they're not part of the sig hash type.
• Wallet developers could be encouraged to always use Taproot but with an empty (i.e. invalid) root and then just always spend it directly, making payments a little bit more efficient and all unrevealed smart contract payments much more private.
• If we don't change the sighash algorithm (too much), it would make it easier for multicoin hardware wallets that support taproot to also support Logos.
• If we add OP_ECADD and OP_ECMUL, smart contract developers can still use recurrent smart contracts in the same way they currently do.

I would suggest modifying BIP341 in the following way:

• Add a dedicated opcode, OP_TAPROOT, which always fails script execution immediately.
• In VerifyScript, if a scriptPubKey has the form <32 bytes> OP_TAPROOT, instead of executing it, run the taproot verification in its place.
• Instead of using the witness stack, use the normal stack from scriptSig.
• Add FORKID 0x40 to the hash_type.

We need a CLI tool for contributors that is easy to download and run. (Preferrably written in Go) that can do a few things:

• Auto-format code with autopep8/clang-format
• Enforce structured commit messages (machine parseable)
• Produce release notes based on information in the structured commits.

Bitwise operators like AND, OR and XOR are often used for arithmetic.

However, since OP_AND, OP_OR and OP_XOR in Script require the arguments to be of the same length and because numbers are minimally encoded in Script, they often can't be used in that context.

For example, say we want to set the least 4 significant bits of a number to 1, then we'd like to use the following script:

<num> OP_15 OP_OR (2 opcodes, 2 bytes)

However, this fails for all inputs that have more than 8 bits (or 7 if values are unsigned), since 0x0f has 1 byte.

Instead, one has to do this (assuming 63+1-bit integers):

<num> OP_8 OP_NUM2BIN 0x000000000000000f OP_OR OP_BIN2NUM (3 opcodes, 13 bytes),

or

<num> OP_8 OP_NUM2BIN OP_15 OP_8 OP_NUM2BIN OP_OR OP_BIN2NUM (4 opcodes, 7 bytes),

Which is very inefficient.

One possible fix is to allow arguments of different length, pick the longest of both arguments, padding the other one with zeros, and then applying the bitwise operator.

From time to time, it would still require a OP_BIN2NUM after the operator if superfluous zeros remain, but that would be required in the current workaround, too, so there are no additional costs.

Change the repo description please.

This software is no longer a "Bitcoin Cash" daemon.

We're exclusively using ASERT, so it makes no sense to keep them.

We need to do several changes to the cashaddr spec:

1. Change the prefix to match the coin name
2. Update the character mapping from bytes to ASCII
3. Change version byte to remove size so we can support irregular address sizes (for example, taproot or other contracts)

These are currently allowed in unexecuted IF branches, which we don’t want.

Should be fixed before launch

We can perform these operations with OP_SCRIPTVERSION taproot, or for multisig p2sh. The only thing to consider is that OP_CHECKMULTISIG outputs can be indexed on all the various valid keys.

In order to reduce variance, and appease a number of users, we need to set the block time to 2 minutes before launch.

If we want to migrate script versions, or use nVersion for optional flags, we need to be able to fetch it easily during a TXN spend. Currently, the UTXO db does not store the transaction version. It may be wise to pipe this through the database before launch so that we can use it in a later hardfork. Otherwise, the UTXOdb will need a migration.

We need to spin up a seeder and add it to the codebase so that new instances can easily start connecting to the rest of the network.

Due to resetting to a new genesis, all checkpoint hashes are now invalid. We need to scrub these.

Allowing OP_TRUE as a standard output will allow a canonical way to send miners SLP tokens.

Remove activation check code e.g. IsUAHFEnabled

CODESEPARATOR can potentially be used for a DoS attach against the nodes w/ BIP143. We should investigate this and see if we need to disable more than one CODESEPARATOR for transactions using BIP143 sighashes.

This avoids potential DoS vectors and gives us more options for upgrades.

This will break a lot of tests

In #95 we introduced a backport from core to introduce a helper function for a single round of SHA256. However, the OP_CHECKDATASIG implementation uses CSHA256 still. This should likely be cleaned up to be consistent with the new helper function, and the future uses.

Implement bitshifts.

I don't know how yet. A simple numeric shift might be not as useful as a raw shift on any bytestring (as in BSV). However, the latter might not always be a numeric shift.

We need to setup a build server for this project so we have automated tests. TeamCity was in use for ABC and is a great product. We should continue to use this, but it means setting it up ourselves and paying for hosting. That's probably a few hundred a month.

With the new header, getblocktemplate is overkill because sending all txs in a block is both unnecessary and inefficient.

Instead, we can just send the blockheader (+extended metadata), and let the miners do their thing.

A webhook might be an idea so miners immediately get informed of new headers when txs (i.e. merkle root) or blocks (i.e. prev block hash) changes, without having to continuously poll the thing.

Autoconf is archaic and support for it should be removed. Nuff said.

Currently, there is no available metrics coming out of the bitcoin daemon. It may make sense to instrument it with an openmetrics API. This will allow various performance data to be scraped and exported to prometheus, or any other generic metric system.

See: https://github.com/jupp0r/prometheus-cpp

Finish https://reviews.bitcoinabc.org/D1927 and land it on this repository. This will enable us to use more complicated fee calculations to ensure people don't bloat the UTXO set when spamming.

Bitcoin ABC and Bitcoin Cash use the same port as Bitcoin, which prevents them from being ran on the same machine as Bitcoin Core, or each other. However, this was done due to the fact that they forked the ledger from these other networks. Because Lotus is starting fresh, we can use a different port to enable infrastructure providers to more easily spin up a our daemon.

We should use port 7633

The Qt Wallet is a significant amount of time to maintain, and a burden on the build system as well. Nobody should be recommended to use it directly, as there are plenty of 3rd party wallets available. Even if we would like a wallet as part of the project, it would be better to ensure that it can be something that runs along side cashd.

We may want to implement OP_MUL before launch. Especially if we implement 64 bit integers. Adding this to milestones, but we might kick it out.

• x P OP_ECMUL: Takes the EC point P and multilplies it with integer x.
• P Q OP_ECADD: Takes the EC points P and Q and adds them.

These are generally useful opcodes for all sorts of cryptographic schemes, which could add more privacy by tweaking public keys.

They also allow advanced txs introspection for Taproot (see #88), e.g. for verifying a branch of an output.

Both opcodes increment the SigChecks by one, so DoS attacks are prevented by default.

There used to be a few possible attacks on Script, but at this point there shouldn't be any remaining, especially with limiting all smart contracts to P2SH.

Due to the introduction of these changes, all known attacks are mitigated:

• Enforce standardness as consensus rule (#39)
• CLEANSTACK
• O(1) OP_IF/NOTIF/ELSE/ENDIF script implementation (https://reviews.bitcoinabc.org/D8837)
• SigChecks
• Limit OP_NUM2BIN to 68 bytes (#60)

General mitigation of attacks

In general, enforcement of P2SH already neuters attacks, for two reasons:

• All scripts are limited to 520 bytes, not 10000.
• All scripts must be in the scriptSig. Therefore, blocks grow linear to the number of opcodes used. Without P2SH, anything could be in a UTXO but the scriptSig could be as small as 0 bytes, allowing very small txs that are ridiculously expensive to verify.

Former attacks:

OP_IF abuse

Source: https://bitslog.com/2017/04/17/new-quadratic-delays-in-bitcoin-scripts/

Fixed here https://reviews.bitcoinabc.org/D8837.

Rock-and-ROLL

Source: https://bitslog.com/2017/04/17/new-quadratic-delays-in-bitcoin-scripts/

Fixed by the CLEANSTACK rule. Rolled stack items have to be cleaned up, which requires 500 opcodes.

Quadratic sighash remains in Segwitv0/BCH/BSV digest algorithms

Source: https://gist.github.com/markblundeberg/c2c88d25d5f34213830e48d459cbfb44

Fixed by enforcement of P2SH and SigChecks. Also, the script Mark describes is longer than 520 bytes (therefore invalid in P2SH) and pushes more than 1650 bytes in the scriptSig, which is non-standard.

OP_NUM2BIN + OP_HASH256

Source: None

This would hash a lot of data using 0 520 OP_NUM2BIN OP_HASH256 repeatedly.

Fixed by limiting OP_NUM2BIN to 68 bytes, and by enforcement of P2SH.

Conclusion

It's therefore deemed safe to increase the number of opcodes per script to 400.

Bitcoin BTC added support for SHA256 scripts in BIP141, with this rationale:

The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent BIP16 P2SH output

Given it’s The Current Year, collisions will become easier and easier, and the incentive will rise once smart contract usage picks up. Especially smart contract vaults with lots of time-locked coins might be at risk.

We can do the same but add it in the same way as P2SH, by making this script standard and making it return true for the check if it is a Pay-To-Script-Hash script:

OP_SHA256 <push 32 bytes> OP_EQUAL

This could then also be repurposed for a collision resistant P2PKH, by putting a <pubkey> OP_CHECKSIG in the Script.

OP_NUM2BIN can be used to generate a lot of zeros on the stack (520 bytes with 1 opcode and 3 bytes). Combined with OP_HASH256 or other opcodes, this can be quite slow.

Also, numbers will never be longer than 68 bytes, so it's kinda ridiculous to allow 520 bytes.

Why 68 bytes?

There's a neat trick for reducing the size of the preimage for the OP_CHECKDATASIG/OP_CHECKSIG transaction introspection. You use ANYONECANPAY, and then with 2 68 OP_NUM2BIN you generate parts 1. (nVersion, here 02000000), 2. (hashPrevouts, here a uint256 of 0x0000......0000) and 3. (hashSequence, here a uint256 of 0x0000......0000).

This saves around 64 bytes for a transaction and only costs 1 opcode. Reducing the OP_NUM2BIN size to 68 keeps that optimization.

Before launch, we need a new netmagic so that nodes from BCH/BTC don't try to talk to our nodes incorrectly. I have no opinion on the netmagic value.

Due to starting a new chain, and adding BIP341 signatures, we have used the 0x20 sighash type bit. However, the signature checker still allows legacy signatures due to the requirement of testing. However the mapping currently is

1. FORKID = BIP341
2. FORKID|BIP341 = BIP341
3. NO FORKID = Legacy

We need to ensure that only FORKID and the FORKID|BIP341 bit combos are valid outside of unit tests prior to launch. We want to reserve the other two combinations for future sighash types.