@oott123 #2
差分攻击，厉害！ 嗯。。考虑一下编码。。

水印形态不只是图像啊！还记得阿里截图的员工被查出来的事情吗？？

既然试卷的内容，字帖的内容都是你能控制的，为啥不在试卷内容中加入“文字指纹”呢？给每个用户分发的都是带不同指纹的试卷。甚至如果可以，每套试卷中的题目都作一些细微变形。比如数学试卷中方程的系数、语文试卷词组的选择。

试卷是分期发放的、一次交费，抄袭一次，永久封号！钱款不退，甚至倒赔！

~~~
@SlipStupig
上面的一段，是#14 楼的“水印版”，加的“文字水印”是：
的 ， 啥 有 的话 的 的 的
的 然后 ！ ！

做这种白板产品的好多啊。这种一般用在什么场景呢？

另外，你的网站好像直接输入 boardos.online 访问不了，不能自动跳转到 https 。必须手动输入 https 才能访问。

水印的形态不只是图像！！还记得阿里截图员工被查出来的事情吗？

既然试卷的内容、字帖的内容都是你能控制的，为什么不在试卷内容中加入“文字指纹”呢？给每个用户分发的都是带有不同指纹的试卷。甚至如果可以的话，每套试卷中的题目都作一些细微的变形。比如数学试卷中的方程系数、语文试卷的词组选择。

试卷是分期发放、一次交费，然后抄袭一次，永久封号！！钱款不退，甚至倒赔！！

@235777178
也不是抬杠，你看下 2 楼的回复，再结合下面 2 个链接，1 个链接是 7 年前的，1 个链接是 2 年前的：
15 款优秀原型产品 ( http://www.woshipm.com/rp/64741.html )
9 款原型工具 ( http://www.chanpin100.com/article/109790 )

现在都流行微交互了 ( https://www.uisdc.com/micro-interactions-why-when-how )
新的原型工具能更流行，肯定是有需求在推动着的吧。

@235777178 分阶段是肯定的。不过，我想要的原型工具，要能应对原型设计的各个阶段。。所以就需要去分析一个原型工具到底是什么，把它的构成要素抽象出来，看看市面上的工具是不是符合，各个工具的侧重点在哪儿。

@DeutschXP #33 这个问题不在“不应该靠技术解决”的范围内吧
@lance6716 #35 不清楚安全多方计算能不能做到。在这个例子里，多方要计算的目标是什么呢？

@murmur #28
你从哪儿看出来我要解决整个“链条”的问题了？ 你说的跟这个主题讨论的根本不在一个范畴。

@weimao #25
我用数据验证了一下你在#15 的方法，看系统如果故意随机漏掉用户的订单，会有多大的概率被发现。

如果将“间谍账号”生成的“间谍订单”的数量固定为 50 个，而系统要故意漏掉总订单数量的 10%，那么
- 实际 100 个订单，其中 50 个“间谍订单”，故意漏掉 10 个订单，不被发现的概率 < (50/100)^10=0.0009
- 实际 1000 个订单，其中 50 个“间谍订单”，故意漏掉 100 个订单，不被发现的概率 < (50/1000)^100=0.00592
- 实际 10000 个订单，其中 50 个“间谍订单”，故意漏掉 1000 个订单，不被发现的概率 < (50/10000)^1000=0.00665
- 实际 100000 个订单，其中 50 个“间谍订单”，故意漏掉 10000 个订单，不被发现的概率 < (50/100000)^10000=0.00673

所以，只要安排 50 个间谍订单，如果系统故意漏掉了 10%的订单，就能被以 99%以上的概率被发现。也就是说，如果大股东想通过故意漏掉 10%的订单来增加自己的收益(大概提高 11%的收益)，那么其他股东发现其作弊的概率高达 99%以上。
这种随机插入“间谍订单”的方法，配合你说的哈希值编号，可以很容易发现大股东的作弊。

你说的 merkel tree 的方法，我再消化一下。

@q197 #23
对对，我想的一种方法就是这个，哈哈，前端的代码是可以审查的。。不过应该需要配合一定的加密签名、然后用户要支持匿名，否则服务器可以针对不同的登录用户提供“差别前端代码”，你懂的。用户匿名的方法，其实可以用“授权下的匿名”( /t/771869 ) 这种。

@libook #21 >“暂时没有办法能 100%保证买家一定是通过统一的渠道交易的” ， “运营股东完全可以开 2 个支付渠道，一个上链，另一个不上链，结算的时候只用链上数据结算，最终还是可以贪掉不上链的部分”

我考虑的都是前端都是公开的情形，可以对前端的代码进行审计。如果交易渠道可以有多个的话，那么这些渠道应该是公开可查的吧。如果是通过针对特定的用户提供“秘密的”交易渠道，那仅仅对前端做检查就不管用了。

不过，正像#10 楼提到的，这种应该用税务审计之类的就可以了吧。

@rain2meng #13
@Veneris #14
用区块链+合约+代币，应该可以解决，就是感觉是牛刀小用了。另外还得考虑代币的价值有波动吧，结算的时候。

@weimao #15
仔细想了下，这个思路还是有漏洞。比如大股东以一定的概率，漏掉订单。然后把其他没有漏掉的单子，排列拼接起来，生成你说的一系列哈希。这种漏单能否被发现，就看小股东伪装用户下的订单数量了。具体的概率计算应该类似于“生日问题”
( https://zh.wikipedia.org/zh-hans/%E7%94%9F%E6%97%A5%E5%95%8F%E9%A1%8C )

@westoy
哎，真实的需求是这样的：

某人要制作一个收费的订阅，用户付月费或年费来订阅其信息。然后这个人可以接受别人的投稿，然后按照约定的比例拿到订阅费。并且自己拿到的订阅费是可以独立验证的，没有被那个人侵吞。

所以，哪里不是正经业务流程了？非要我说实话才行啊。

@Vegetable #7 订单是可以被后台篡改的
@wy315700 #8 学习了，研发可以控制代码，发行可以控制收入。不过主题里的大股东既控制收入又控制代码。

@murmur 查库存这个确实是一个方向。不过如果卖的是可以拷贝的软件之类呢？ 软件的库存不像实物商品，要想各个股东就商品的库存数量认识达成一致，还是需要密码学来处理。

@summic
可以看一下主题里提到的“授权下的匿名”，感叹一下密码学的应用可以达到怎样的高度。
怎么会是伪需求呢？

“各个股东可以验证这一点几乎 100%成立”
这里“几乎 100%”的含义，类似零知识证明里面的“证明了命题以接近 100%的概率成立”。

@wipbssldo
去线下店对比了一下，应该是机器屏幕的问题，或者是哪里配置的有问题，店里的机器没有问题。不过确实找不到哪里的配置有问题，因为之前用的默认配置就有问题。