cashshuffle spec issues

cashshuffle / spec

Specs and documentation for CashShuffle

MIT License

25 stars 17 forks source link

issues

Newest

Newest Most commented Recently updated Oldest Least commented Least recently updated

Update the URL for protobuf specification

#28 dagurval closed 4 years ago
0
Correct dead links

#27 DarrenTa closed 4 years ago
0
Broken Links

#26 DarrenTa closed 4 years ago
1
More Submappings

#25 nopara73 opened 4 years ago
0
What's the difference between message 5b and 6?

#24 MaxHillebrand closed 4 years ago
4
Clarify content of message

#23 MaxHillebrand closed 4 years ago
1
OP_RETURN without OP_RETURN

#22 nopara73 opened 4 years ago
9
Round Public Key is Shared too late

#21 nopara73 closed 4 years ago
6
Link to overview and white paper is broken

#20 BitLox opened 4 years ago
2
make clear outputs are negative

#19 MaxHillebrand closed 4 years ago
0
Typo: remove "moves"

#18 nopara73 closed 4 years ago
0
Fix typo: in order -> in order to

#17 nopara73 closed 4 years ago
0
Fix typo TOR -> Tor

#16 nopara73 closed 4 years ago
0
fusion idea: hiding number of players

#15 markblundeberg opened 5 years ago
0
Update CASHFUSION.md

#14 markblundeberg closed 4 years ago
0
Fix typos

#13 zander closed 5 years ago
0
Fix some random typos

#12 Mengerian closed 4 years ago
0
Redirect standard protobuf definition to this repo

#11 emergent-reasons opened 5 years ago
0
clarify transaction requirements

#10 emergent-reasons closed 5 years ago
1
Change proposal: add intent field to messages

#9 emergent-reasons opened 5 years ago
0
Multiple rounds

#8 emergent-reasons opened 5 years ago
0
Failed shuffle behavior

#7 emergent-reasons opened 5 years ago
0
Ban behavior: what should be in the spec and what should be implementation details?

#6 emergent-reasons opened 5 years ago
0
bring flowchart from plugin repo

#5 emergent-reasons closed 4 years ago
0
Include version details, requirements (0, 100, 200, 300, ...)

#4 emergent-reasons opened 5 years ago
1
Be more strict about valid messages so that server and clients can identify a failed shuffle and minimize exposure to malicious clients

#3 emergent-reasons opened 5 years ago
0
Clarify: who should receive blame information and what information should they receive?

#2 emergent-reasons closed 4 years ago
3
Initial collection

#1 emergent-reasons closed 5 years ago
0