A new snapshot version, and binary encoding without msgpack.

There are plenty of if not something then panic code, refactor them with general functions, but try to avoid reflect.

Allow a single CosiSignature for transaction.

How can I transfer funds to the nodes in the set testnet? How can I check the transfer result after the transfer? I think it should be in the document, but I think many places are described very vaguely. I don't know which two rpc interfaces to call for transfer and query

Separate the kernel consensus and network sync node, allow a node to only sync and keep a copy of the graph.

A node may have many keys, a signer key may be BLS or Ed25519, payee key, custodian key, etc.

Use the same message compression method as the storage

Thank you!
`wim@wim-ubuntu1804:~/mixin$ go build

github.com/lucas-clemente/quic-go/internal/crypto

../workspace/go/pkg/mod/github.com/lucas-clemente/[email protected]/internal/crypto/key_derivation.go:46:37: cs.KeyLen undefined (type mint.CipherSuiteParams has no field or method KeyLen)
../workspace/go/pkg/mod/github.com/lucas-clemente/[email protected]/internal/crypto/key_derivation.go:47:35: cs.IvLen undefined (type mint.CipherSuiteParams has no field or method IvLen)

github.com/MixinNetwork/mixin/storage

../workspace/go/pkg/mod/github.com/!mixin!network/[email protected]/storage/badger_cache.go:64:19: not enough arguments in call to txn.Commit
have ()
want (func(error))
../workspace/go/pkg/mod/github.com/!mixin!network/[email protected]/storage/badger_genesis.go:33:19: not enough arguments in call to txn.Commit
have ()
want (func(error))
../workspace/go/pkg/mod/github.com/!mixin!network/[email protected]/storage/badger_graph.go:47:19: not enough arguments in call to txn.Commit
have ()
want (func(error))
../workspace/go/pkg/mod/github.com/!mixin!network/[email protected]/storage/badger_graph.go:125:19: not enough arguments in call to txn.Commit
have ()
want (func(error))
../workspace/go/pkg/mod/github.com/!mixin!network/[email protected]/storage/badger_round.go:69:19: not enough arguments in call to txn.Commit
have ()
want (func(error))
../workspace/go/pkg/mod/github.com/!mixin!network/[email protected]/storage/badger_round.go:116:19: not enough arguments in call to txn.Commit
have ()
want (func(error))
../workspace/go/pkg/mod/github.com/!mixin!network/[email protected]/storage/badger_transaction.go:80:19: not enough arguments in call to txn.Commit
have ()
want (func(error))`

By the signature count in past 24 hours?

mixin version v0.12.8-BUILD_VERSION

2021/03/12 00:01:05 AggregateMintWork(edc14960841f8d46a408b09c834a80f40a042fe6c4b632b6bc3b27195a2443e0)
2021/03/12 00:01:05 AggregateMintWork(edc14960841f8d46a408b09c834a80f40a042fe6c4b632b6bc3b27195a2443e0) begin with 0
panic: runtime error: index out of range [0] with length 0

goroutine 938 [running]:
github.com/MixinNetwork/mixin/kernel.(*Chain).AggregateMintWork(0xc00b80d500)
	/root/mixin/kernel/mint.go:71 +0xacc
created by github.com/MixinNetwork/mixin/kernel.(*Node).buildChain
	/root/mixin/kernel/chain.go:88 +0x1ea

Now it takes about 1 week to sync a 70GB final snapshots graph.

Use the withdrawal output confirmed by the domain as an input, and a normal script output to build the rebate transaction.

The rpc concensus test sometimes is stuck forever due to the chain shutdown, code trace seems to be the clc channel.

Since the system is carefully designed to prevent serious incidents like double spending, it's still possible for some nodes to behave incorrectly. The most important one is the node may delay broadcast of a finalized snapshot, thus cause other nodes to make incorrect false claims. So we need some rules to slash this bad node.

Including mint and node state. This could be done along with the slashing rules.

build with following error, any idea?

go build
go: downloading github.com/ethereum/go-ethereum v1.9.8
build github.com/MixinNetwork/mixin: cannot load github.com/ethereum/go-ethereum/common: zip: not a valid zip file

Now that transaction has been in the new binary encoding, time to make snapshot.

Now the configuration file is a plain json, which is not good for human readable, and unable to add comment.
Change the configuration file format to TOML, should have backward compatibilities.

$ go build
报如下错误:

github.com/marten-seemann/qtls

../../marten-seemann/qtls/common.go:1062:20: undefined: cpu.ARM64

This will reduce the snapshot storage by at least half.

https://blockchainatberkeley.blog/alternative-signatures-schemes-14a563d9d562

https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/Schnorr-Signatures--An-Overview.md

https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/src/modules/musig/musig.md

https://godoc.org/github.com/dedis/kyber/sign/cosi

Now all nodes are removed one by one after every Feb 28. This removal is important to ensure security of the nodes software and keys. Some adversary may hack the network one node after the other, and if the hacked node is removed before the adversary gets enough nodes to hack the whole network, then ensures better security.

However, a yearly nodes removal still not secure enough. So here proposes a rolling nodes removal, i.e. all nodes will be removed one by one at any time. Let's say we have 35 nodes at the moment, they have a predefined order. The network will remove the nodes one by one according to the nodes order, and the removed node has the chance to join the network instantly after the removal. And they also has the chance to leave the network without joining again, so it's also feasible to remove the node resigning operation, because this rolling removal is free compared to the 1% penalty of resigning.

A way more faster hash function https://github.com/BLAKE3-team/BLAKE3

Describe the bug
RPC request alwasy return {"error":"bad request"} after normal RPC result

To Reproduce
Run the following Python code:

import requests
data = {'method': 'getinfo', 'params': []}
headers = {'Content-type': 'application/json', 'Accept': 'text/plain'}
r = requests.post('http://127.0.0.1:8007', json=data, headers=headers)
print(r.text)

Got the output like this:

...
[0,0],"e4a9ef941e1dfe221391056be6a9a79e5b29d863d466e8a7eefe028d7d2e8385":[0,0],"f1b6abb60f743554c1e3df97faf17af3f7c8f2a2d1ac4ccdd394514ded442082":[0,0]}},"timestamp":"2021-10-06T11:05:31.000000001+08:00","uptime":"3m41.091330692s","version":"v0.13.4-BUILD_VERSION"}}{"error":"bad request"}

Expected behavior
Successfull RPC request should not return {"error":"bad request"} at the end of normal return

Related log
2021/10/06 11:17:01 server.go:3159: http: superfluous response.WriteHeader call from github.com/MixinNetwork/mixin/rpc.(*Render).render (http.go:60)

Environment (please complete the following information):

• OS: macOS 11.6
• Version v0.13.4-f8c5c31c2ee83263b3fb73f4bee1dda6db288755]

Additional context
Sounds like this issue originates from the following code:

I am trying to use the rpc with a local testnet. So I am able to start the local testnet with

`$ mixin setuptestnet

$ mixin kernel -dir /tmp/mixin-7001 -port 7001
$ mixin kernel -dir /tmp/mixin-7002 -port 7002
$ mixin kernel -dir /tmp/mixin-7003 -port 7003
$ mixin kernel -dir /tmp/mixin-7004 -port 7004
$ mixin kernel -dir /tmp/mixin-7005 -port 7005
$ mixin kernel -dir /tmp/mixin-7006 -port 7006
$ mixin kernel -dir /tmp/mixin-7007 -port 7007`

However, when I tried

`./mixin getroundlink

Post http://127.0.0.1:8239: dial tcp 127.0.0.1:8239: connect: connection refused
`
Can anyone help me out?
It failed.

To improve the security, it's good to start eliminating dependencies. Domains are a good start point.

• filecoin
• bchutil
• dcrd
• monero
• stellar

There may be a process to clean up the database and remove used and old enough UTXOs, as these data could be calculated from transactions if ever needed in the future.

BLS makes better promise, its simplicity for aggregated signatures can easily replace our cosi workflow.

According to the launch of Ethereum 2.0 Beacon it's a good time to have the first mature and audited BLS implementation

0. https://github.com/supranational/blst
1. https://twitter.com/technocrypto/status/1330150362427387910
2. https://www.reddit.com/r/ethfinance/comments/jghide/daily_general_discussion_october_23_2020/g9sz7jm/?context=8&depth=9
3. https://medium.com/cryptoadvance/bls-signatures-better-than-schnorr-5a7fe30ea716

The transaction or snapshot struct may change in the future, so the signature and hash function should respect the version info of these changes.

When compiling for a Linux amd64 server on a Mac with the command: GOOS=linux GOARCH=amd64 go build, I got:

# github.com/valyala/gozstd
../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/stream.go:14:48: undefined: DefaultCompressionLevel
../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/stream.go:31:59: undefined: CDict
../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/stream.go:35:64: undefined: CDict
../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/stream.go:47:20: undefined: Writer
../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/stream.go:56:22: undefined: NewWriterLevel
../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/stream.go:101:61: undefined: DDict
../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/stream.go:110:6: undefined: Reader
../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/stream.go:117:8: undefined: NewReader

After reading the gozstd document and some blogs, I installed some cross compilers with: brew install FiloSottile/musl-cross/musl-cross.

Then, I tried to build using CC=x86_64-linux-musl-gcc CXX=x86_64-linux-musl-g++ GOOS=linux GOARCH=amd64 CGO_ENABLED=1 go build, and got:

# github.com/valyala/gozstd
/usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: ../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/libzstd_linux_amd64.a(zdict.o): in function ZDICT_analyzeEntropy': zdict.c:(.text+0x7ce): undefined reference to __fprintf_chk'
/usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: ../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/libzstd_linux_amd64.a(zdict.o): in function ZDICT_analyzePos': zdict.c:(.text+0x1832): undefined reference to __fprintf_chk'
/usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: zdict.c:(.text+0x18c2): undefined reference to __fprintf_chk' /usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: ../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/libzstd_linux_amd64.a(zdict.o): in function ZDICT_finalizeDictionary':
zdict.c:(.text+0x1b24): undefined reference to __fprintf_chk' /usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: ../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/libzstd_linux_amd64.a(zdict.o): in function ZDICT_trainFromBuffer_unsafe_legacy':
zdict.c:(.text+0x1d54): undefined reference to __fprintf_chk' /usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: ../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/libzstd_linux_amd64.a(zdict.o):zdict.c:(.text+0x1dd4): more undefined references to __fprintf_chk' follow
/usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: ../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/libzstd_linux_amd64.a(entropy_common.o): in function FSE_readNCount': entropy_common.c:(.text+0x345): undefined reference to __memcpy_chk'
/usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: ../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/libzstd_linux_amd64.a(fastcover.o): in function FASTCOVER_buildDictionary.isra.6': fastcover.c:(.text+0x3a9): undefined reference to __fprintf_chk'
/usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: fastcover.c:(.text+0x44f): undefined reference to __fprintf_chk' /usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: fastcover.c:(.text+0x488): undefined reference to __fprintf_chk'
/usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: ../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/libzstd_linux_amd64.a(fastcover.o): in function FASTCOVER_ctx_init': fastcover.c:(.text+0x8a0): undefined reference to __fprintf_chk'
/usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: fastcover.c:(.text+0x8e6): undefined reference to __fprintf_chk' /usr/local/Cellar/musl-cross/0.9.9/libexec/bin/../lib/gcc/x86_64-linux-musl/9.2.0/../../../../x86_64-linux-musl/bin/ld: ../../GO_PATH/pkg/mod/github.com/valyala/[email protected]/libzstd_linux_amd64.a(fastcover.o):fastcover.c:(.text+0xbc7): more undefined references to __fprintf_chk' follow
collect2: error: ld returned 1 exit status

How can I compile for Linux amd64 on a Mac?

when i compile ,I get follows:

github.com/MixinNetwork/mixin/network

network/quic.go:73:3: unknown field 'HandshakeTimeout' in struct literal of type quic.Config
network/quic.go:103:3: unknown field 'HandshakeTimeout' in struct literal of type quic.Config

For both amd64 and arm64

Add a replay command to sync from a snapshots directory.

when i compile ,I get follows:

github.com/MixinNetwork/mixin/network

network/quic.go:73:3: unknown field 'HandshakeTimeout' in struct literal of type quic.Config
network/quic.go:103:3: unknown field 'HandshakeTimeout' in struct literal of type quic.Config

Describe the bug
The AggregatePublicKey function does not check if each public key is valid. As a result, an attacker is able to produce a valid multi-party signature without the knowledge of other parties' private key.

To Reproduce
Suppose that there are 2 parties with public keys PK_1, PK_2, signing a message msg. The aggregated public key of these two parties is PK_1 + PK_2.

One of the parties, say party 1, can produce a valid signature for msg by posting his fake public key PK_1' with the following property: PK_1' + PK_2 = xG, where x is known to party 1. In this case, the private key x is the aggregated private key for the two parties. Therefore, party 1 can sign msg without party 2 being involved.

Expected behavior
A proof of exponential should be used here to make sure a signer knows his private key.

I am a big fan of Mixin, looking into Mixin since the beginning. Since Mixin is a blockchain project, I am hoping Mixin could be more transparent to investors? I have a few questions on the technical side. Where is Mixin Consensus Mechanism? Are you going to publicize the consensus algorithm in the future? How do you leverage TEE in the system? How BFT-DAG fit into the system? I am hoping you could give a brief answer.

Enable the kernel custodian. The key is a threshold multisig custodian between kernel nodes. And kernel nodes change everyday, the custodian can do a new key setup everyday.

Another possible solution is to leave the custodian key unchanged, unless some custodian changing threshold kernel nodes changed. Let's say we have 42 nodes, and the multisig threshold is 29, and the custodian changing threshold is (42-29)/2=6. So if 6 kernel nodes changed, the custodian needs a new multisig setup.

Kernel nodes change only considered changed when its custodian identifier changed, custodian identifier is similar to the payee key or something, not the same as the signer key.

https://www.gnu.org/software/bash/manual/html_node/Programmable-Completion.html

Mixin Kernel doesn't offer instant total order, but it's possible to get this order from a single node instantly. The node should sign the order along side the snapshot and guarantee the consistency.

Light node which has staked 1 XIN must send voting transactions periodically to retain its reputation to receive reward from the pool. One of their votes is vote the total order hash of some kernel node, and whenever some kernel node receives conflicting votes for its order, and this vote is valid because it includes the signature of the kernel node. Then this kernel node will be slashed instantly.

• Light node vote SDK
• Vote transaction
• Strict topology sync mode

There are random panics with the master branch.

I can't find these packages

The transaction implementation in BadgerDB is critical for the Kernel consensus, and we can't make the core consensus implementation rely on such a large external project which we have no deep understanding.

希望为项目做贡献，但是没有开发或构建文档，会造成许多困难

Hope to contribute to the project, but without the development or construction of documentation, it will cause many difficulties

https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts

I followed the steps in README to setup a local testnet but was met with the following error 2018/12/01 12:11:46 election routine peer error HandshakeTimeout: Crypto handshake did not complete in time.

Could you help me resolve the issue ?

OS: macOS Mojave.
go version: go1.11.2 darwin/amd64

Ensure that the domain deposit and withdrawal are available for multisig keys.

Should lock the dependencies with Go modules https://blog.golang.org/using-go-modules