作者Hirorio (重新开始)
看板DigiCurrency
标题[闲聊] 默默的 maicoin也加入BCH选项
时间Thu Feb 8 17:03:17 2018
今天登入，发现在之前三种币之外，多了BCH字眼...
之前转过BCH 只是三节点确认，花了一小时
同时的ETH几乎分到帐
这币有点垃圾，但中国这麽大基数支撑，可能也还有一席之地
最近掉到有朝半年前价格前进的趋势...
这币这阵熊市跌的比比特还凶 但开放交易的场所好像越来越多
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 106.105.65.129
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/DigiCurrency/M.1518080600.A.DE9.html
1F：推 yys310: 设计的区块时间就不同了...... 02/08 17:04
2F：→ ww578912tw: BCH还好吧 之前4000的糕点是洗上去的bulltrap 02/08 17:14
3F：→ ww578912tw: 一下就掉到3000出头 真正维持比较久是在2500上下 02/08 17:15
4F：推 tcn1john: bch都骂垃圾了，btc怎麽办...不过btc生态系砍掉重练eth 02/08 17:25
5F：→ tcn1john: 等币，比被bch接收的可能大？ 02/08 17:25
6F：推 EthereumPTT: BCH真的是市值前10里面我最不懂的 02/08 18:50
7F：推 Andyss: bch 猜过几次短线都失败收场 走势太机歪难测了 现在完全 02/08 19:09
8F：→ Andyss: 不敢碰 02/08 19:09
9F：→ sean123362: 有吗？为什麽我登入後没看到bch 02/08 19:33
11F：推 mithuang: BCH是最多团队在维护,中本聪唯一传人都推荐,好币不买吗? 02/08 20:11
12F：推 teason: BCH >BTC 02/08 20:31
13F：推 allen139443: 不知道为什麽大家都很看虽bch 理由是什麽 02/08 20:54
14F：推 DarkerDuck: 要等三个确认是交易所都这样规定 02/08 20:56
15F：→ DarkerDuck: 其实以Bitcoin类型区块链的稳定度，一个确认就差不多 02/08 20:57
16F：→ DarkerDuck: 价格和生态系不一定正相关，不然ETH市值早就超越BTC 02/08 21:00
17F：→ DarkerDuck: 这波熊市来讲，BCH大概还会继续跌，毫无吸引人的题材 02/08 21:01
18F：→ DarkerDuck: 长期来看，BCH只要好好做好自己的扩容研发工作 02/08 21:02
19F：→ DarkerDuck: 在下波牛市来临时，BTC的市值将会被抢掉一大半 02/08 21:03
20F：→ DarkerDuck: BCH本身的设计并不需要很复杂的智能合约sharding 02/08 21:11
21F：→ DarkerDuck: 就可以轻易往上on-chain扩容，测试网路可以跑到1GB 02/08 21:12
22F：→ DarkerDuck: 这优势就是来至於没有复杂的智能额约以及10分钟区块 02/08 21:13
23F：→ DarkerDuck: 其实我觉得BTC很多参数的设计就是为了方便全球扩容 02/08 21:13
24F：→ DarkerDuck: 甚至可以说是中本聪早就算好要这样做 02/08 21:14
25F：→ DarkerDuck: 10分钟区块时间在後来几乎没有加密货币使用 02/08 21:14
26F：→ DarkerDuck: 但是这也导致比特币区块链极端稳定，几乎不出现孤立块 02/08 21:15
27F：→ DarkerDuck: 比特币当初一些智能合约的opcode还被封印掉 02/08 21:16
28F：→ DarkerDuck: 但反而让扩容只需要专注在频宽瓶颈上面就好 02/08 21:17
29F：→ DarkerDuck: 而用智能合约做sharding是等於在CAP问题上选择了AP 02/08 21:19
30F：→ DarkerDuck: 作为货币的应用来讲,舍弃掉Consistency等於放弃安全性 02/08 21:23
31F：→ Hirorio: 三节点确认要一小时感觉有点久... 02/08 22:22
32F：→ DarkerDuck: 平均是十分钟一个确认，三个确认平均是三十分钟 02/08 22:24
33F：推 DarkerDuck: 若要快速的话，还是以Ripple最为快速 02/08 22:25
34F：→ DarkerDuck: ETH很多交易所也不敢一分钟到帐，区块链不太稳定 02/08 22:27
35F：→ DarkerDuck: 其实以交易所交易来讲，我觉得匿踪币市场也蛮大的 02/08 22:56
36F：→ DarkerDuck: 交易所都要做KYC，等於金流全被看光光 02/08 22:57
37F：→ DarkerDuck: 甚至有被锁帐户的危险，而且匿踪币也还是跑得比BTC快 02/08 22:57
38F：→ DarkerDuck: 所以有些交易所才会用XMR当作计价货币之一 02/08 22:58
39F：推 qxxrbull: 不知道会不会有去中心化的ETH、BTC/XMR的交易所 02/08 23:24
40F：推 asoedarren: 早就有了 02/08 23:58
41F：→ DarkerDuck: 以ETH当结算货币的很早就有 02/09 00:00
42F：→ DarkerDuck: 其他币种要靠Atomic cross-chain trading 02/09 00:01
43F：推 anna5566gu: 想请问板大，之前爬文时，看到有个说法说 02/09 11:06
44F：→ anna5566gu: "BTC宁愿推动闪电网路，宁愿用其他方式来替代扩容，是 02/09 11:07
45F：→ anna5566gu: 因为直接增加区块容量并没有从"根本"上解决问题 02/09 11:08
46F：→ anna5566gu: 难道交易量一直增加你就一直扩容吗？" 02/09 11:08
47F：→ DarkerDuck: 正好相反，扩容才是从"根本"解决问题 02/09 11:08
48F：→ DarkerDuck: 你看Internet就知道，网路塞车难道加一层就解决了吗? 02/09 11:09
49F：→ anna5566gu: 所以跟随交易量的增加而扩容，究竟会产生甚麽问题？ 02/09 11:09
50F：→ DarkerDuck: 这实在是太荒谬了，网路层往上加只能增加功能性 02/09 11:09
51F：→ DarkerDuck: 你无法用增加层数的方式从"根本"解决问题 02/09 11:09
52F：→ DarkerDuck: 扩容问题我以前就过，你无论用什麽方式都要对於CAP 02/09 11:10
53F：→ DarkerDuck: 问题做取舍，闪电网路其实就是偷懒版的零确认交易 02/09 11:11
54F：→ DarkerDuck: 闪电网路交易全网其实无共识，所以交易就是有风险 02/09 11:11
55F：→ DarkerDuck: 是一种牺牲Consistency的扩容方式，几乎所有off-chain 02/09 11:12
56F：→ DarkerDuck: 的扩容方式都如此，必定会增加网路的Partition 02/09 11:12
57F：→ DarkerDuck: 而对於金流的安全性来说，没有共识就有可能双花 02/09 11:13
58F：→ DarkerDuck: 乙太网路的sharding其实也是主要用在智能合约上 02/09 11:14
59F：→ DarkerDuck: 一个智能合约平台不需要全部的ETH的节点都去跑 02/09 11:14
60F：→ DarkerDuck: 但是对於金流应用来说，sharding并无法带来太大的益处 02/09 11:15
61F：→ DarkerDuck: 因为所有节点都需要跑金流啊 02/09 11:15
62F：→ DarkerDuck: 像闪电网路的这种做法我觉得做到payment channel就 02/09 11:19
63F：→ DarkerDuck: 差不多极限了，因为你根本无法解决闪电网路的routing 02/09 11:19
64F：→ DarkerDuck: 除非你用中心化的方式去搞，就像现在的Internet一样 02/09 11:20
65F：→ DarkerDuck: 而扩容的瓶颈在频宽，闪电网路完全无法缩减使用频宽 02/09 11:23
66F：→ DarkerDuck: 反而加上更多的通道资讯需要广播，根本大爆炸 02/09 11:25
67F：推 timwu: D大讲得很好,补充一下我在以太这边观察到的状况,雷电网路这 02/09 15:21
68F：→ timwu: 里还正在做, 光看 contract 搞了四份感觉此协定异常复杂啊 02/09 15:24
69F：→ timwu: 所以官方先推个拿掉routing的uRaiden,这个code倒是十分简洁 02/09 15:25
70F：→ timwu: 拿掉routing,代表双方必须直通无法借道,user要maintain的 02/09 15:28
71F：→ timwu: channel数变多,换到真实世界体验就是,每来一家新的店消费 02/09 15:30
72F：→ timwu: 都要单独充值,第一笔交易都要等一下下. 但带来的好处很多 02/09 15:33
73F：→ timwu: 稳定性大幅提升,没有payment hub问题,0交易费,不需广播 02/09 15:35
74F：推 DarkerDuck: payment channel最早提出就是高频交易和微交易在用的 02/09 15:53
75F：推 DarkerDuck: 譬如看串流影片以分计费，那payment channel极端适合 02/09 15:55
76F：→ DarkerDuck: 但却被硬搞成一个处理所有支付的扩容方案就非常奇怪了 02/09 15:56
77F：→ DarkerDuck: 以前有个p2p的wifi分享网路fon,可以靠分享wifi赚钱 02/09 16:24
78F：→ DarkerDuck: 不过金流部分就麻烦了，假如那个时候就有比特币 02/09 16:24
79F：→ DarkerDuck: 像这种大型p2p的分享wifi社群应该玩的起来 02/09 16:26
80F：→ DarkerDuck: 只要费用比电信网路便宜，用payment channel 02/09 16:27
81F：→ DarkerDuck: 还可以做到免注册以秒计费 02/09 16:28
82F：→ DarkerDuck: 从寻找AP，比价，付款，连线，完全自动化 02/09 16:31
83F：推 a2935373: 闪电网路如果拿现实生活来比喻的话差不多就是你去买点数 02/09 16:41
84F：→ a2935373: 卡或者储值卡... 然後会不会倒不保证 02/09 16:41
85F：→ DarkerDuck: 闪电网路的设计是可以避免对方跑路的风险啦 02/09 16:54
86F：→ DarkerDuck: 只是先决条件是你必须一直监视网路状态 02/09 16:55
87F：→ DarkerDuck: 因为闪电网路都是零确认交易，并无网路共识 02/09 16:55
88F：→ DarkerDuck: 要先锁钱，又要一直在线收钱和避免对方诈欺，很麻烦 02/09 16:56
89F：推 Ayukawayen: 如果像储值卡这种单向的应用，应该只有收款方必需保持 02/09 17:42
90F：→ Ayukawayen: 一直在线？因为对消费者来说，他的钱是一直变少的，店 02/09 17:42
91F：→ Ayukawayen: 家发比较旧的记录上链结算，消费者的钱只会变多而已。 02/09 17:42
92F：→ Ayukawayen: 店家就要担心消费者把旧记录上链，但店家要持续监视链 02/09 17:43
93F：→ Ayukawayen: 上状态相对比较容易一点。 02/09 17:43
94F：→ Ayukawayen: 不过要是只有单向付款，其实有更简单更不会出问题的解 02/09 17:43
95F：→ Ayukawayen: 法就是了。 02/09 17:43
96F：→ Ayukawayen: 不晓得这样对闪电网路的认知对不对？ 02/09 17:44
97F：→ DarkerDuck: 单向的话的确如此，但就发挥不了闪电网路的好处 02/09 17:53
98F：→ DarkerDuck: 因为锁住的钱很快就会用光，要开新通道 02/09 17:53
99F：→ DarkerDuck: 还不如就直接payment channel连过去就好 02/09 17:54
100F：推 Ayukawayen: 用完再花100美金的手续费储值 (爆) 02/09 18:06
101F：→ DarkerDuck: 100美金是blockstream的目标啦，不过fee market 02/09 18:17
102F：→ DarkerDuck: 看起来玩不起来了，直接用其他加密货币不就好了 02/09 18:18
103F：→ DarkerDuck: BTC还是乖乖的当他的黄金就好 02/09 18:19
104F：推 timwu: 回一下uRaiden的做法,使用者充值的钱是锁在合约里,合约纪录 02/10 09:43
105F：→ timwu: 收付款地址与充值数,遇到首充,续充,合议结束,争议结束都是 02/10 09:46
106F：→ timwu: 在链上合约处理,链下每笔微交易都会带个余额证明,内容就是 02/10 09:50
107F：→ timwu: "这个通道内,我承认余额还剩xx元喔" 做最小链下保护 02/10 09:54
108F：→ timwu: 有争议时,争议方把余额证明提交给合约,合约将锁起来的钱 02/10 09:58
109F：→ timwu: 依照证明内容把钱拨给收款方与退给付款方後结束通道. 02/10 09:59