Inside a Bitcoin Mining Operation in Hong Kong - Hong Wrong

Gratitude for Dash

It's easy to forget how far we've come in so little time. A decade ago free-market money in digital form was a completely foreign concept to 99% of the world. Now, pretty much everyone I talk to knows about "blockchain" and "bitcoin", and we have hundreds of teams working to make free-market digital cash a reality. A few of those teams have really compelling products - it's no longer a science project - and Dash is leading the way.
I am continually checking the wider landscape to see if any projects besides Dash are starting to catch up to us. I see great innovators and hard work, but I don't see the progress that I see in Dash. Our closest competitor is Bitcoin Cash. They seem to have the right vision, digital cash, and they have excellent engineers and a passionate community, but something is missing.
Several large Bitcoin Cash mining pools recently announced a proposal/plan to start paying developers with part of the block reward. The concept is the same as Dash (pay developers with inflation), but the distribution mechanism is vastly different. I've been closely following the discussion and debates in btc and it's been fascinating to see the reactions. Some general trends I'm seeing:
What I'm grateful for is that Dash has worked out many, if not all, of these issues already. We are paying developers, and we have control over who gets the funds, how much they get, and for how long they get them. For the most part we don't care if funded entities set up corporations to run their internal affairs or not (we can always defund if a problem arises with either approach for a specific scope). While the specific funding decisions can be difficult, the process is smooth, and getting more streamlined every month. We don't consider our superblock to be a "coercive tax". Those who do have already left, can leave at any time, or simply don't join. It's all understood, and is completely voluntary.
We just finished another successful month of funding where we voluntarily paid developers, marketers, and other workers roughly 5,700 DASH (~$655,000) for the value their work has or is expected to bring to Dash. That's how the real world operates - people do valuable work and they get paid for it, mutual benefit, every transacting party is happy (or at least should be).
And while we're on the subject of this month's payouts, I'd like to add a few of my observations. I was pretty happy to see how the funding shook out. I've had my criticisms of the Dash Investment Foundation, but they took action (revised their proposal at a lower cost) to address one of them this month. Whether my or other people's input had anything to do with their revision doesn't matter as much as that they made the revision, and their proposal passed. I expected Dash Force to resubmit their proposal with a lower ask. There was plenty of time to do so. I didn't want them to receive zero (their work is more valuable than zero), but it seems I was not alone in the opinion that the juice was simply not worth the squeeze with that proposal. I hope they re-evaluate and come back next month with a more compelling value proposition. Speaking of value propositions, one last observation about this month's superblock: If you haven't already, check out the DACH's DCW marketing proposal. I was skeptical when I first skimmed it, but when I came back to it later in the cycle and read it through all the way (including the resources they linked to) I was pretty impressed by the thought that went into it. I'm cautiously optimistic about its potential.
I'm truly grateful for our independent Dash contractors. It takes guts and heart to submit proposals. It's not always the most rewarding job. I'm grateful all of you who put in proposals, and keep coming back, especially after you get kicked in the teeth by MNOs. Those of you who have not been through this process don't have much justification to complain.
I know this is a long post, and thank you for reading, but I'd like to circle back to Bitcoin Cash. I said they were missing something. What? They really are missing two crucial components.
  1. Governance - They have to rely on social media platforms and hash wars to make decisions. It's clunky.
  2. Funding - They have to rely on donations (time and money) and/or outside interest groups. It's dangerous and slow.
I don't see Bitcoin Cash figuring out either of these things anytime soon. I've seen the debates, it's not an easy situation for them. I honestly hope I'm wrong and that they do figure them out, because I want stiffer competition for Dash, and more options for digital cash. For now, and for the foreseeable future, I'm just grateful we have Dash. We're getting closer to user-friendly digital cash every day.
submitted by ISkiAtAlta to dashpay [link] [comments]

r/Bitcoin recap - December 2019

Hi Bitcoiners!
I’m back with the 36th monthly Bitcoin news recap.
For those unfamiliar, each day I pick out the most popularelevant/interesting stories in Bitcoin and save them. At the end of the month I release them in one batch, to give you a quick (but not necessarily the best) overview of what happened in bitcoin over the past month.
You can see recaps of the previous months on
A recap of Bitcoin in December 2019
Regulation & Politics
Archeology (Financial Incumbents)
Price & Trading
Fun & Other
submitted by SamWouters to Bitcoin [link] [comments]

Transcript of discussion between an ASIC designer and several proof-of-work designers from #monero-pow channel on Freenode this morning

[08:07:01] lukminer contains precompiled cn/r math sequences for some blocks:
[08:07:11] try that with RandomX :P
[08:09:00] tevador: are you ready for some RandomX feedback? it looks like the CNv4 is slowly stabilizing, hashrate comes down...
[08:09:07] how does it even make sense to precompile it?
[08:09:14] mine 1% faster for 2 minutes?
[08:09:35] naturally we think the entire asic-resistance strategy is doomed to fail :) but that's a high-level thing, who knows. people may think it's great.
[08:09:49] about RandomX: looks like the cache size was chosen to make it GPU-hard
[08:09:56] looking forward to more docs
[08:11:38] after initial skimming, I would think it's possible to make a 10x asic for RandomX. But at least for us, we will only make an ASIC if there is not a total ASIC hostility there in the first place. That's better for the secret miners then.
[08:13:12] What I propose is this: we are working on an Ethash ASIC right now, and once we have that working, we would invite tevador or whoever wants to come to HK/Shenzhen and we walk you guys through how we would make a RandomX ASIC. You can then process this input in any way you like. Something like that.
[08:13:49] unless asics (or other accelerators) re-emerge on XMR faster than expected, it looks like there is a little bit of time before RandomX rollout
[08:14:22] 10x in what measure? $/hash or watt/hash?
[08:14:46] watt/hash
[08:15:19] so you can make 10 times more efficient double precisio FPU?
[08:16:02] like I said let's try to be productive. You are having me here, let's work together!
[08:16:15] continue with RandomX, publish more docs. that's always helpful.
[08:16:37] I'm trying to understand how it's possible at all. Why AMD/Intel are so inefficient at running FP calculations?
[08:18:05] midipoet ([email protected]/web/ has joined #monero-pow
[08:18:17] hardware development works the other way round. We start with 1) math then 2) optimization priority 3) hw/sw boundary 4) IP selection 5) physical implementation
[08:22:32] This still doesn't explain at which point you get 10x
[08:23:07] Weren't you the ones claiming "We can accelerate ProgPoW by a factor of 3x to 8x." ? I find it hard to believe too.
[08:30:20] sure
[08:30:26] so my idea: first we finish our current chip
[08:30:35] from simulation to silicon :)
[08:30:40] we love this stuff... we do it anyway
[08:30:59] now we have a communication channel, and we don't call each other names immediately anymore: big progress!
[08:31:06] you know, we russians have a saying "it was smooth on paper, but they forgot about ravines"
[08:31:12] So I need a bit more details
[08:31:16] ha ha. good!
[08:31:31] that's why I want to avoid to just make claims
[08:31:34] let's work
[08:31:40] RandomX comes in Sep/Oct, right?
[08:31:45] Maybe
[08:32:20] We need to audit it first
[08:32:31] ok
[08:32:59] we don't make chips to prove sw devs that their assumptions about hardware are wrong. especially not if these guys then promptly hardfork and move to the next wrong assumption :)
[08:33:10] from the outside, this only means that hw & sw are devaluing each other
[08:33:24] neither of us should do this
[08:33:47] we are making chips that can hopefully accelerate more crypto ops in the future
[08:33:52] signing, verifying, proving, etc.
[08:34:02] PoW is just a feature like others
[08:34:18] sech1: is it easy for you to come to Hong Kong? (visa-wise)
[08:34:20] or difficult?
[08:34:33] or are you there sometimes?
[08:34:41] It's kind of far away
[08:35:13] we are looking forward to more RandomX docs. that's the first step.
[08:35:31] I want to avoid that we have some meme "Linzhi says they can accelerate XYZ by factor x" .... "ha ha ha"
[08:35:37] right? we don't want that :)
[08:35:39] doc is almost finished
[08:35:40] What docs do you need? It's described pretty good
[08:35:41] so I better say nothing now
[08:35:50] we focus on our Ethash chip
[08:36:05] then based on that, we are happy to walk interested people through the design and what else it can do
[08:36:22] that's a better approach from my view than making claims that are laughed away (rightfully so, because no silicon...)
[08:36:37] ethash ASIC is basically a glorified memory controller
[08:36:39] sech1: tevador said something more is coming (he just did it again)
[08:37:03] yes, some parts of RandomX are not described well
[08:37:10] like dataset access logic
[08:37:37] RandomX looks like progpow for CPU
[08:37:54] yes
[08:38:03] it is designed to reflect CPU
[08:38:34] so any ASIC for it = CPU in essence
[08:39:04] of course there are still some things in regular CPU that can be thrown away for RandomX
[08:40:20] uncore parts are not used, but those will use very little power
[08:40:37] except for memory controller
[08:41:09] I'm just surprised sometimes, ok? let me ask: have you designed or taped out an asic before? isn't it risky to make assumptions about things that are largely unknown?
[08:41:23] I would worry
[08:41:31] that I get something wrong...
[08:41:44] but I also worry like crazy that CNv4 will blow up, where you guys seem to be relaxed
[08:42:06] I didn't want to bring up anything RandomX because CNv4 is such a nailbiter... :)
[08:42:15] how do you guys know you don't have asics in a week or two?
[08:42:38] we don't have experience with ASIC design, but RandomX is simply designed to exactly fit CPU capabilities, which is the best you can do anyways
[08:43:09] similar as ProgPoW did with GPUs
[08:43:14] some people say they want to do asic-resistance only until the vast majority of coins has been issued
[08:43:21] that's at least reasonable
[08:43:43] yeah but progpow totally will not work as advertised :)
[08:44:08] yeah, I've seen that comment about progpow a few times already
[08:44:11] which is no surprise if you know it's just a random sales story to sell a few more GPUs
[08:44:13] RandomX is not permanent, we are expecting to switch to ASIC friendly in a few years if possible
[08:44:18] yes
[08:44:21] that makes sense
[08:44:40] linzhi-sonia: how so? will it break or will it be asic-able with decent performance gains?
[08:44:41] are you happy with CNv4 so far?
[08:45:10] ah, long story. progpow is a masterpiece of deception, let's not get into it here.
[08:45:21] if you know chip marketing it makes more sense
[08:45:24] linzhi-sonia: So far? lol! a bit early to tell, don't you think?
[08:45:35] the diff is coming down
[08:45:41] first few hours looked scary
[08:45:43] I remain skeptical: I only see ASICs being reasonable if they are already as ubiquitous as smartphones
[08:45:46] yes, so far so good
[08:46:01] we kbew the diff would not come down ubtil affter block 75
[08:46:10] yes
[08:46:22] but first few hours it looks like only 5% hashrate left
[08:46:27] looked
[08:46:29] now it's better
[08:46:51] the next worry is: when will "unexplainable" hashrate come back?
[08:47:00] you hope 2-3 months? more?
[08:47:05] so give it another couple of days. will probably overshoot to the downside, and then rise a bit as miners get updated and return
[08:47:22] 3 months minimum turnaround, yes
[08:47:28] nah
[08:47:36] don't underestimate asicmakers :)
[08:47:54] you guys don't get #1 priority on chip fabs
[08:47:56] 3 months = 90 days. do you know what is happening in those 90 days exactly? I'm pretty sure you don't. same thing as before.
[08:48:13] we don't do any secret chips btw
[08:48:21] 3 months assumes they had a complete design ready to go, and added the last minute change in 1 day
[08:48:24] do you know who is behind the hashrate that is now bricked?
[08:48:27] innosilicon?
[08:48:34] hyc: no no, and no. :)
[08:48:44] hyc: have you designed or taped out a chip before?
[08:48:51] yes, many years ago
[08:49:10] then you should know that 90 days is not a fixed number
[08:49:35] sure, but like I said, other makers have greater demand
[08:49:35] especially not if you can prepare, if you just have to modify something, or you have more programmability in the chip than some people assume
[08:50:07] we are chipmakers, we would never dare to do what you guys are doing with CNv4 :) but maybe that just means you are cooler!
[08:50:07] and yes, programmability makes some aspect of turnaround easier
[08:50:10] all fine
[08:50:10] I hope it works!
[08:50:28] do you know who is behind the hashrate that is now bricked?
[08:50:29] inno?
[08:50:41] we suspect so, but have no evidence
[08:50:44] maybe we can try to find them, but we cannot spend too much time on this
[08:50:53] it's probably not so much of a secret
[08:51:01] why should it be, right?
[08:51:10] devs want this cat-and-mouse game? devs get it...
[08:51:35] there was one leak saying it's innosilicon
[08:51:36] so you think 3 months, ok
[08:51:43] inno is cool
[08:51:46] good team
[08:51:49] IP design house
[08:51:54] in Wuhan
[08:52:06] they send their people to conferences with fake biz cards :)
[08:52:19] pretending to be other companies?
[08:52:26] sure
[08:52:28] ha ha
[08:52:39] so when we see them, we look at whatever card they carry and laugh :)
[08:52:52] they are perfectly suited for secret mining games
[08:52:59] they made at most $6 million in 2 months of mining, so I wonder if it was worth it
[08:53:10] yeah. no way to know
[08:53:15] but it's good that you calculate!
[08:53:24] this is all about cost/benefit
[08:53:25] then you also understand - imagine the value of XMR goes up 5x, 10x
[08:53:34] that whole "asic resistance" thing will come down like a house of cards
[08:53:41] I would imagine they sell immediately
[08:53:53] the investor may fully understand the risk
[08:53:57] the buyer
[08:54:13] it's not healthy, but that's another discussion
[08:54:23] so mid-June
[08:54:27] let's see
[08:54:49] I would be susprised if CNv4 ASICs show up at all
[08:54:56] surprised*
[08:54:56] why?
[08:55:05] is only an economic question
[08:55:12] yeah should be interesting. FPGAs will be near their limits as well
[08:55:16] unless XMR goes up a lot
[08:55:19] no, not *only*. it's also a technology question
[08:55:44] you believe CNv4 is "asic resistant"? which feature?
[08:55:53] it's not
[08:55:59] cnv4 = Rabdomx ?
[08:56:03] no
[08:56:07] cnv4=cryptinight/r
[08:56:11] ah
[08:56:18] CNv4 is the one we have now, I think
[08:56:21] since yesterday
[08:56:30] it's plenty enough resistant for current XMR price
[08:56:45] that may be, yes!
[08:56:55] I look at daily payouts. XMR = ca. 100k USD / day
[08:57:03] it can hold until October, but it's not asic resistant
[08:57:23] well, last 24h only 22,442 USD :)
[08:57:32] I think 80 h/s per watt ASICs are possible for CNv4
[08:57:38] linzhi-sonia where do you produce your chips? TSMC?
[08:57:44] I'm cruious how you would expect to build a randomX ASIC that outperforms ARM cores for efficiency, or Intel cores for raw speed
[08:57:48] curious
[08:58:01] yes, tsmc
[08:58:21] Our team did the world's first bitcoin asic, Avalon
[08:58:25] and upcoming 2nd gen Ryzens (64-core EPYC) will be a blast at RandomX
[08:58:28] designed and manufactured
[08:58:53] still being marketed?
[08:59:03] linzhi-sonia: do you understand what xmr wants to achieve, community-wise?
[08:59:14] Avalon? as part of Canaan Creative, yes I think so.
[08:59:25] there's not much interesting oing on in SHA256
[08:59:29] Inge-: I would think so, but please speak
[08:59:32] hyc: yes
[09:00:28] linzhi-sonia: i am curious to hear your thoughts. I am fairly new to this space myself...
[09:00:51] oh
[09:00:56] we are grandpas, and grandmas
[09:01:36] yet I have no problem understanding why ASICS are currently reviled.
[09:01:48] xmr's main differentiators to, let's say btc, are anonymity and fungibility
[09:01:58] I find the client terribly slow btw
[09:02:21] and I think the asic-forking since last may is wrong, doesn't create value and doesn't help with the project objectives
[09:02:25] which "the client" ?
[09:02:52] Monero GUI client maybe
[09:03:12] MacOS, yes
[09:03:28] What exactly is slow?
[09:03:30] linzhi-sonia: I run my own node, and use the CLI and Monerujo. Have not had issues.
[09:03:49] staying in sync
[09:03:49] linzhi-sonia: decentralization is also a key principle
[09:03:56] one that Bitcoin has failed to maintain
[09:04:39] hmm
[09:05:00] looks fairly decentralized to me. decentralization is the result of 3 goals imo: resilient, trustless, permissionless
[09:05:28] don't ask a hardware maker about physical decentralization. that's too ideological. we focus on logical decentralization.
[09:06:11] physical decentralization is important. with bulk of bitnoin mining centered on Chinese hydroelectric dams
[09:06:19] have you thought about including block data in the PoW?
[09:06:41] yes, of course.
[09:07:39] is that already in an algo?
[09:08:10] hyc: about "centered on chinese hydro" - what is your source? the best paper I know is this:
[09:09:01] linzhi-sonia: do you mine on your ASICs before you sell them?
[09:09:13] besides testing of course
[09:09:45] that paper puts Chinese btc miners at 60% max
[09:10:05] tevador: I think everybody learned that that is not healthy long-term!
[09:10:16] because it gives the chipmaker a cost advantage over its own customers
[09:10:33] and cost advantage leads to centralization (physical and logical)
[09:10:51] you guys should know who finances progpow and why :)
[09:11:05] but let's not get into this, ha ha. want to keep the channel civilized. right OhGodAGirl ? :)
[09:11:34] tevador: so the answer is no! 100% and definitely no
[09:11:54] that "self-mining" disease was one of the problems we have now with asics, and their bad reputation (rightfully so)
[09:13:08] I plan to write a nice short 2-page paper or so on our chip design process. maybe it's interesting to some people here.
[09:13:15] basically the 5 steps I mentioned before, from math to physical
[09:13:32] linzhi-sonia: the paper you linked puts 48% of bitcoin mining in Sichuan. the total in China is much more than 60%
[09:13:38] need to run it by a few people to fix bugs, will post it here when published
[09:14:06] hyc: ok! I am just sharing the "best" document I know today. it definitely may be wrong and there may be a better one now.
[09:14:18] hyc: if you see some reports, please share
[09:14:51] hey I am really curious about this: where is a PoW algo that puts block data into the PoW?
[09:15:02] the previous paper I read is from here
[09:15:38] hyc: you said that already exists? (block data in PoW)
[09:15:45] it would make verification harder
[09:15:49] linzhi-sonia:
[09:15:51] but for chips it would be interesting
[09:15:52] we discussed the possibility about a year ago
[09:16:05] oh good links! thanks! need to read...
[09:16:06] I think that paper by dryja was original
[09:17:53] since we have a nice flow - second question I'm very curious about: has anyone thought about in-protocol rewards for other functions?
[09:18:55] we've discussed micropayments for wallets to use remote nodes
[09:18:55] you know there is a lot of work in other coins about STARK provers, zero-knowledge, etc. many of those things very compute intense, or need to be outsourced to a service (zether). For chipmakers, in-protocol rewards create an economic incentive to accelerate those things.
[09:19:50] whenever there is an in-protocol reward, you may get the power of ASICs doing something you actually want to happen
[09:19:52] it would be nice if there was some economic reward for running a fullnode, but no one has come up with much more than that afaik
[09:19:54] instead of fighting them off
[09:20:29] you need to use asics, not fight them. that's an obvious thing to say for an asicmaker...
[09:20:41] in-protocol rewards can be very powerful
[09:20:50] like I said before - unless the ASICs are so useful they're embedded in every smartphone, I dont see them being a positive for decentralization
[09:21:17] if they're a separate product, the average consumer is not going to buy them
[09:21:20] now I was talking about speedup of verifying, signing, proving, etc.
[09:21:23] they won't even know what they are
[09:22:07] if anybody wants to talk about or design in-protocol rewards, please come talk to us
[09:22:08] the average consumer also doesn't use general purpose hardware to secure blockchains either
[09:22:14] not just for PoW, in fact *NOT* for PoW
[09:22:32] it requires sw/hw co-design
[09:23:10] we are in long-term discussions/collaboration over this with Ethereum, Bitcoin Cash. just talk right now.
[09:23:16] this was recently published though suggesting more uptake though I guess
[09:23:29] I find it pretty hard to believe their numbers
[09:24:03] well
[09:24:09] sorry, original article:
[09:24:11] just talk, no? rumors
[09:24:18] college students are already more educated than the average consumer
[09:24:29] we are not seeing many such customers anymore
[09:24:30] it's data from cisco monitoring network traffic
[09:24:33] and they're always looking for free money
[09:24:48] of course anyone with "free" electricity is inclined to do it
[09:24:57] but look at the rates, cannot make much money
[09:26:06] Ethereum is a bloated collection of bugs wrapped in a UI. I suppose they need all the help they can get
[09:26:29] Bitcoin Cash ... just another get rich quick scheme
[09:26:38] hmm :)
[09:26:51] I'll give it back to you, ok? ha ha. arrogance comes before the fall...
[09:27:17] maye we should have a little fun with CNv4 mining :)
[09:27:25] ;)
[09:27:38] come on. anyone who has watched their track record... $75M lost in ETH at DAO hack
[09:27:50] every smart contract that comes along is just waiting for another hack
[09:27:58] I just wanted to throw out the "in-protocol reward" thing, maybe someone sees the idea and wants to cowork. maybe not. maybe it's a stupid idea.
[09:29:18] linzhi-sonia: any thoughts on CN-GPU?
[09:29:55] CN-GPU has one positive aspect - it wastes chip area to implement all 18 hash algorithms
[09:30:19] you will always hear roughly the same feedback from me:
[09:30:52] "This algorithm very different, it heavy use floating point operations to hurt FPGAs and general purpose CPUs"
[09:30:56] the problem is, if it's profitable for people to buy ASIC miners and mine, it's always more profitable for the manufacturer to not sell and mine themselves
[09:31:02] "hurt"
[09:31:07] what is the point of this?
[09:31:15] it totally doesn't work
[09:31:24] you are hurting noone, just demonstrating lack of ability to think
[09:31:41] what is better: algo designed for chip, or chip designed for algo?
[09:31:43] fireice does it on daily basis, CN-GPU is a joke
[09:31:53] tevador: that's not really true, especially in a market with such large price fluctuations as cryptocurrency
[09:32:12] it's far less risky to sell miners than mine with them and pray that price doesn't crash for next six months
[09:32:14] I think it's great that crypto has a nice group of asicmakers now, hw & sw will cowork well
[09:32:36] jwinterm yes, that's why they premine them and sell after
[09:32:41] PoW is about being thermodynamically and cryptographically provable
[09:32:45] premining with them is taking on that risk
[09:32:49] not "fork when we think there are asics"
[09:32:51] business is about risk minimization
[09:32:54] that's just fear-driven
[09:33:05] Inge-: that's roughly the feedback
[09:33:24] I'm not saying it hasn't happened, but I think it's not so simple as saying "it always happens"
[09:34:00] jwinterm: it has certainly happened on BTC. and also on XMR.
[09:34:19] ironically, please think about it: these kinds of algos indeed prove the limits of the chips they were designed for. but they don't prove that you cannot implement the same algo differently! cannot!
[09:34:26] Risk minimization is not starting a business at all.
[09:34:34] proof-of-gpu-limit. proof-of-cpu-limit.
[09:34:37] imagine you have a money printing machine, would you sell it?
[09:34:39] proves nothing for an ASIC :)
[09:35:05] linzhi-sonia: thanks. I dont think anyone believes you can't make a more efficient cn-gpu asic than a gpu - but that it would not be orders of magnitude faster...
[09:35:24] ok
[09:35:44] like I say. these algos are, that's really ironic, designed to prove the limitatios of a particular chip in mind of the designer
[09:35:50] exactly the wrong way round :)
[09:36:16] like the cache size in RandomX :)
[09:36:18] beautiful
[09:36:29] someone looked at GPU designs
[09:37:31] linzhi-sonia can you elaborate? Cache size in RandomX was selected to fit CPU cache
[09:37:52] yes
[09:38:03] too large for GPU
[09:38:11] as I said, we are designing the algorithm to exactly fit CPU capabilities, I do not claim an ASIC cannot be more efficient
[09:38:16] ok!
[09:38:29] when will you do the audit?
[09:38:35] will the results be published in a document or so?
[09:38:37] I claim that single-chip ASIC is not viable, though
[09:39:06] you guys are brave, noone disputes that. 3 anti-asic hardforks now!
[09:39:18] 4th one coming
[09:39:31] 3 forks were done not only for this
[09:39:38] they had scheduled updates in the first place
[09:48:10] Monero is the #1 anti-asic fighter
[09:48:25] Monero is #1 for a lot of reasons ;)
[09:48:40] It's the coin with the most hycs.
[09:48:55] mooooo
[09:59:06] sneaky integer overflow, bug squished
[10:38:00] p0nziph0ne ([email protected]/vpn/privateinternetaccess/p0nziph0ne) has joined #monero-pow
[11:10:53] The convo here is wild
[11:12:29] it's like geo-politics at the intersection of software and hardware manufacturing for thermoeconomic value.
[11:13:05] ..and on a Sunday.
[11:15:43] midipoet: hw and sw should work together and stop silly games to devalue each other. to outsiders this is totally not attractive.
[11:16:07] I appreciate the positive energy here to try to listen, learn, understand.
[11:16:10] that's a start
[11:16:48] <-- p0nziph0ne ([email protected]/vpn/privateinternetaccess/p0nziph0ne) has quit (Quit: Leaving)
[11:16:54] we won't do silly mining against xmr "community" wishes, but not because we couldn'd do it, but because it's the wrong direction in the long run, for both sides
[11:18:57] linzhi-sonia: I agree to some extent. Though, in reality, there will always be divergence between social worlds. Not every body has the same vision of the future. Reaching societal consensus on reality tomorrow is not always easy
[11:20:25] absolutely. especially at a time when there is so much profit to be made from divisiveness.
[11:20:37] someone will want to make that profit, for sure
[11:24:32] Yes. Money distorts.
[11:24:47] Or of the two
[11:26:35] Too much physical money will distort rays of light passing close to it indeed.
submitted by jwinterm to Monero [link] [comments]

Long live decentralized bitcoin(!) A reading list

Newbs might not know this, but bitcoin recently came out of an intense internal drama. Between July 2015 and August 2017 bitcoin was attacked by external forces who were hoping to destroy the very properties that made bitcoin valuable in the first place. This culminated in the creation of segwit and the UASF (user activated soft fork) movement. The UASF was successful, segwit was added to bitcoin and with that the anti-decentralization side left bitcoin altogether and created their own altcoin called bcash. Bitcoin's price was $2500, soon after segwit was activated the price doubled to $5000 and continued rising until a top of $20000 before correcting to where we are today.
During this drama, I took time away from writing open source code to help educate and argue on reddit, twitter and other social media. I came up with a reading list for quickly copypasting things. It may be interesting today for newbs or anyone who wants a history lesson on what exactly happened during those two years when bitcoin's very existence as a decentralized low-trust currency was questioned. Now the fight has essentially been won, I try not to comment on reddit that much anymore. There's nothing left to do except wait for Lightning and similar tech to become mature (or better yet, help code it and test it)
In this thread you can learn about block sizes, latency, decentralization, segwit, ASICBOOST, lightning network and all the other issues that were debated endlessly for over two years. So when someone tries to get you to invest in bcash, remind them of the time they supported Bitcoin Unlimited.
For more threads like this see UASF

Summary / The fundamental tradeoff

A trip to the moon requires a rocket with multiple stages by gmaxwell (must read)
Bram Cohen, creator of bittorrent, argues against a hard fork to a larger block size
gmaxwell's summary of the debate
Core devs please explain your vision (see luke's post which also argues that blocks are already too big)
Mod of btc speaking against a hard fork
It's becoming clear to me that a lot of people don't understand how fragile bitcoin is
Blockchain space must be costly, it can never be free
Charlie Lee with a nice analogy about the fundamental tradeoff
gmaxwell on the tradeoffs
jratcliff on the layering

Scaling on-chain will destroy bitcoin's decentralization

Peter Todd: How a floating blocksize limit inevitably leads towards centralization [Feb 2013] mailing list with discussion on reddit in Aug 2015
Nick Szabo's blog post on what makes bitcoin so special
There is academic research showing that even small (2MB) increases to the blocksize results in drastic node dropoff counts due to the non-linear increase of RAM needed.
Reddit summary of above link. In this table, you can see it estimates a 40% drop immediately in node count with a 2MB upgrade and a 50% over 6 months. At 4mb, it becomes 75% immediately and 80% over 6 months. At 8, it becomes 90% and 95%.
Larger block sizes make centralization pressures worse (mathematical)
Talk at scalingbitcoin montreal, initial blockchain synchronization puts serious constraints on any increase in the block size with transcript
Bitcoin's P2P Network: The Soft Underbelly of Bitcoin someone's notes: reddit discussion
In adversarial environments blockchains dont scale
Why miners will not voluntarily individually produce smaller blocks
Hal Finney: bitcoin's blockchain can only be a settlement layer (mostly interesting because it's hal finney and its in 2010)
petertodd's 2013 video explaining this
luke-jr's summary
Another jratcliff thread

Full blocks are not a disaster

Blocks must be always full, there must always be a backlog
Same as above, the mining gap means there must always be a backlog talk: transcript:
Backlogs arent that bad
Examples where scarce block space causes people to use precious resources more efficiently
Full blocks are fine
High miner fees imply a sustainable future for bitcoin
gmaxwell on why full blocks are good
The whole idea of the mempool being "filled" is wrong headed. The mempool doesn't "clog" or get stuck, or anything like that.


What is segwit

luke-jr's longer summary
Charlie Shrem's on upgrading to segwit
Original segwit talk at scalingbitcoin hong kong + transcript
Segwit is not too complex
Segwit does not make it possible for miners to steal coins, contrary to what some people say
Segwit is required for a useful lightning network It's now known that without a malleability fix useful indefinite channels are not really possible.
Clearing up SegWit Lies and Myths:
Segwit is bigger blocks
Typical usage results in segwit allowing capacity equivalent to 2mb blocks

Why is segwit being blocked

Jihan Wu (head of largest bitcoin mining group) is blocking segwit because of perceived loss of income
Witness discount creates aligned incentives
or because he wants his mining enterprise to have control over bitcoin

Segwit is being blocked because it breaks ASICBOOST, a patented optimization used by bitmain ASIC manufacturer

Details and discovery by gmaxwell
Reddit thread with discussion
Simplified explaination by jonny1000
Bitmain admits their chips have asicboost but they say they never used it on the network (haha a likely story)
Worth $100m per year to them (also in gmaxwell's original email)
Other calculations show less
This also blocks all these other cool updates, not just segwit
Summary of bad consequences of asicboost
Luke's summary of the entire situation
Prices goes up because now segwit looks more likely
Asicboost discovery made the price rise
A pool was caught red handed doing asicboost, by this time it seemed fairly certain that segwit would get activated so it didnt produce as much interest as earlier and and
This btc user is outraged at the entire forum because they support Bitmain and ASICBOOST
Antbleed, turns out Bitmain can shut down all its ASICs by remote control:

What if segwit never activates

What if segwit never activates? with and


bitcoinmagazine's series on what lightning is and how it works
The Lightning Network ELIDHDICACS (Explain Like I Don’t Have Degrees in Cryptography and Computer Science)
Ligtning will increases fees for miners, not lower them
Cost-benefit analysis of lightning from the point of view of miners
Routing blog post by rusty and reddit comments
Lightning protocol rfc
Blog post with screenshots of ln being used on testnet video
Video of sending and receiving ln on testnet
Lightning tradeoffs
Beer sold for testnet lightning and
Lightning will result in far fewer coins being stored on third parties because it supports instant transactions
jgarzik argues strongly against LN, he owns a coin tracking startup
luke's great debunking / answer of some misinformation questions
Lightning centralization doesnt happen
roasbeef on hubs and charging fees and

Immutability / Being a swiss bank in your pocket / Why doing a hard fork (especially without consensus) is damaging

A downside of hard forks is damaging bitcoin's immutability
Interesting analysis of miners incentives and how failure is possible, don't trust the miners for long term
waxwing on the meaning of cash and settlement
maaku on the cash question
Digital gold funamentalists gain nothing from supporting a hard fork to larger block sizes
Those asking for a compromise don't understand the underlying political forces
Nobody wants a contentious hard fork actually, anti-core people got emotionally manipulated
The hard work of the core developers has kept bitcoin scalable
Recent PRs to improve bitcoin scaleability ignored by the debate
gmaxwell against hard forks since 2013
maaku: hard forks are really bad

Some metrics on what the market thinks of decentralization and hostile hard forks

The price history shows that the exchange rate drops every time a hard fork threatens:
and this example from 2017 btc users lose money
price supporting theymos' moderation
old version
older version
about 50% of nodes updated to the soft fork node quite quickly

Bitcoin Unlimited / Emergent Consensus is badly designed, changes the game theory of bitcoin

Bitcoin Unlimited was a proposed hard fork client, it was made with the intention to stop segwit from activating
A Future Led by Bitcoin Unlimited is a Centralized Future
Flexible transactions are bugged
Bugged BU software mines an invalid block, wasting 13 bitcoins or $12k employees are moderators of btc
miners don't control stuff like the block size
even gavin agreed that economic majority controls things
fork clients are trying to steal bitcoin's brand and network effect, theyre no different from altcoins
BU being active makes it easier to reverse payments, increases wasted work making the network less secure and giving an advantage to bigger miners
bitcoin unlimited takes power away from users and gives it to miners
bitcoin unlimited's accepted depth
BU's lying propaganda poster

BU is bugged, poorly-reviewed and crashes

bitcoin unlimited allegedly funded by kraken stolen coins
Other funding stuff
A serious bug in BU
A summary of what's wrong with BU:

Bitcoin Unlimited Remote Exploit Crash 14/3/2017
BU devs calling it as disaster also btc deleted a thread about the exploit
Summary of incident
More than 20 exchanges will list BTU as an altcoin
Again a few days later

User Activated Soft Fork (UASF)

site for it, including list of businesses supporting it
luke's view
threat of UASF makes the miner fall into line in litecoin
UASF delivers the goods for vertcoin
UASF coin is more valuable
All the links together in one place
p2sh was a uasf
jgarzik annoyed at the strict timeline that segwit2x has to follow because of bip148
Committed intolerant minority
alp on the game theory of the intolerant minority
The risk of UASF is less than the cost of doing nothing
uasf delivered the goods for bitcoin, it forced antpool and others to signal (May 2016) "When asked specifically whether Antpool would run SegWit code without a hard fork increase in the block size also included in a release of Bitcoin Core, Wu responded: “No. It is acceptable that the hard fork code is not activated, but it needs to be included in a ‘release’ of Bitcoin Core. I have made it clear about the definition of ‘release,’ which is not ‘public.’”"
Screenshot of peter rizun capitulating

Fighting off 2x HF
b2x is most of all about firing core

Misinformation / sockpuppets
three year old account, only started posting today
Why we should not hard fork after the UASF worked:


Good article that covers virtually all the important history
Interesting post with some history pre-2015
The core scalabality roadmap + my summary from 3/2017 my summary
History from summer 2015
Brief reminders of the ETC situation
Longer writeup of ethereum's TheDAO bailout fraud
Point that the bigblocker side is only blocking segwit as a hostage
jonny1000's recall of the history of bitcoin

Misc (mostly memes)

libbitcoin's Understanding Bitcoin series (another must read, most of it)
github commit where satoshi added the block size limit
hard fork proposals from some core devs
blockstream hasnt taken over the entire bitcoin core project
blockstream is one of the good guys
Forkers, we're not raising a single byte! Song lyrics by belcher
Some stuff here along with that cool photoshopped poster
Nice graphic
gmaxwell saying how he is probably responsible for the most privacy tech in bitcoin, while mike hearn screwed up privacy
Fairly cool propaganda poster
btc tankman
asicboost discovery meme
gavin wanted to kill the bitcoin chain
stuff that btc believes
after segwit2x NYA got agreed all the fee pressure disappeared, laurenmt found they were artificial spam
theymos saying why victory isnt inevitable
with ignorant enemies like these its no wonder we won ""So, once segwit2x activates, from that moment on it will require a coordinated fork to avoid the up coming "baked in" HF. ""
a positive effect of bcash, it made blockchain utxo spammers move away from bitcoin
summary of craig wright, jihan wu and roger ver's positions
Why is bitcoin so strong against attack?!?! (because we're motivated and awesome)
what happened to #oldjeffgarzik
big blockers fully deserve to lose every last bitcoin they ever had and more
gavinandresen brainstorming how to kill bitcoin with a 51% in a nasty way
Roger Ver as bitcoin Judas
A bunch of tweets and memes celebrating UASF | | | | | | | | | | | |
submitted by belcher_ to Bitcoin [link] [comments]

Educate Yourself - My Top Picks for news sources, YouTube channels, and podcasts

Why do I need to know what is going on in the world of cryptocurrency and blockchain? I'm just here to trade and make money.
I saw someone post a couple of days ago about how they have held Ethereum for a while, but had recently "done some research" and discovered that Ethereum was Turing complete and that "surely this must be one of Ethereum's most important features." At that moment, I realized how many people who post here have no idea what the hell they are talking about. If this post can help us become collectively smarter and more informed, and thereby elevate the quality of the discussion in this community, then it will have served its purpose.
If you want to get smart on any topic, you need to learn and keep learning from others who are knowledgeable. Things evolve incredibly quickly in the world of crypto and it is very easy to fall out of the loop on the latest happenings. Since most of you have money on the line (in the form of ETH holdings), that should be all of the incentive you need to stay informed. Every effective traditional investor I have ever met researches the hell out of every stock they buy (before they buy it), but also keeps in the know on every major development that company and its competitors have. This is doubly important in the world of crypto where markets can move much faster and the potential for scams and major disruption are much higher.
But what about ethtrader? Can't I just get all of my news here?
Getting all your news from ethtrader (especially the Daily) is like getting all of your news while standing in line at the grocery store, talking to other people who are reading the National Enquirer. Sure, you may happen upon a useful tidbit of knowledge, but you may also get wrong info that leads you to make bad decisions if you are not informed. But one thing is for sure: it is entertaining.
My Top 5 News Source Picks
There is no TL;DR for developing real wisdom and insight. Start reading full articles on a regular basis for topics related to crypto/blockchain. At a minimum, put the sites below into a folder on your browser's bookmarks tab and open them daily. Or get an RSS reader and make sure you methodically read every single article that comes out on these sites. Newsify is a great RSS reader for iOS users. For either iOS or Android, you could check out Feedly.
Honorable Mentions: You may also want to check out TrustNodes, but their content feels a bit more editorial-ish. There are also many great posts from devs on Medium. Sign up for an account and they'll start e-mailing you some good picks based upon your reading history.
My Top 5 YouTube Channel Picks
Honestly, there are so many YouTube channels these days, I can't keep up with them. I'll often watch the suggested content from YouTube as a way to discover new vloggers.
Honorable Mentions: Love him or hate him, you can't ignore Andreas...good for quick hits on crypto-philosophy. Real Crypto recently caught my attention as well, with excellent quality TA. Chris Dunn is also very well-established and solid for TA. DataDash is also very informative for ICO analysis and TA. I also like MrYukonC, who is a mod here and talks about topics from this sub on occasion. He only posts when he has something to say (which is fairly episodically), but I think that is a good thing.
My Top 3 Podcast Picks
I only have time to listen to so many podcasts, but here are the three that I listen to on a regular basis.
Honorable Mention: Many folks also mentioned that they like the Ether Review, which I also listen to when the topic is of interest.
That's it. Hope you all found that helpful. If you have any information sources you'd recommend, please share them!
EDIT: Made a few corrections and added two additional sources I left out initially.
submitted by DCinvestor to ethtrader [link] [comments]

Samson Mow’s on 8BTC’s AMA: BU Are Low-Level CopyCats and We Do Support Onchain Scaling

Samson Mow, the COO of BTCC, has completed his AMA on 8btc on 2 Dec.
Samson has faced all the harsh questions raised and said BU is “awful” and he supports onchain Scaling.
We have move all the answers typed by Mr. Mow in person here.
Let’s see:
Q: How do you comment on BU?
A: For BU, I think it’s indeed an awful software. Actually it’s just a redesign based on Bitcoin Core as 99% of the codes are still those of Bitcoin Core. BU just has made some tiny changes. In developing BU, there are serval bugs in BU but they claim these bugs are just bugs from Bitcoin Core itself. Members from Core can tell the so called “bugs from Bitcoin Core itself” are simply caused by BU’s developers. BU is bad at coding and BU has not been through thorough tests. Many coders including Chinese and Westerners all thought BU’s codes are bad.
Besides, BU team actually has achieved nothing till now. If we say Bitcoin is a Ferrari with 100 Core members maintaining it, then BU team simply don’t know what a Ferrari is. BU only repairs bikes or even bikes are beyond their ability. All of these are because BU never has created or maintained any crypto currency. They even have never released any altcoin. I would rather believe in MaidSafeCoin or Dash’s teams than believe in BU.
Furthermore. BU changed the bitcoin’s rule of “ consensus-based principle”. BU is not based on consensus. Bitcoin’s rules are not made for mining but for users to decide the blocksize based on consensus. In order to gain support, BU now suddenly say bitcoin is created for mining, which is actually not even the thought of the developers of BU. Developers(of BU) also said they need to make some changes to conform to the consensus-based principle of bitcoin.
BU is just a form of political maneuvering that is being taken advantage of, just like Bitcoin XT and Bitcoin Classic. Those who support BU are actually not all for BU. The want to achieve their ulterior motives by supporting BU, say they want to scale blocksize, to alienate Core team or they just want to prove they are correct. Their reasons for supporting BU are all far-fetched or wrong.
(from ID Bitcoiners) Q :Does BTCC support onchain scaling ?
Yes, BTCC support onchain scaling.:)
We support any plan of scaling both on and off chain as long as they are safe and have been under thorough tests. SegeWit in essence is onchain scaling as it can make the block size bigger and enlarge the effective capacity of the blockchain for bitcoins.
Many people still think SW is not onchain scaling. But in fact SW is the fastest scaling onchain plan till now. Most of the people within the community oppose a hasty hard-fork; If we can reach consensus on SW, then we can achieve onchain scaling in several months, making it a reality to have bigger blocksize and capacity for more transactions.
Q:BTCC supports SW as mining pool(miners) or as an exchange.
A: we support SW as believe it can improve bitcoin and enlarge the capacity of block, making outstanding technologies like lighting possible. This will bring an all win situation for bitcoin’s traders, miners, buyers or holders. We have made the supportive decision based on our analysis of it and its future potential.
Q: under what circumstances will BTCC give up running a bitcoin app in production with activated SW soft-fork?
I don’t think I have any reason to give up SegeWit till now as it will bring many improvements to bitcoin. It fixes bitcoin’s malleability. If SW is activated, the use of lightening network becomes possible. So from technical angle, I will not give up SW.
But there are also chances for us to give up SW. Like if other mining pools give us pressure then we may make concessions. If the activation phase of SW comes to an end, then we might also give up SW. But in general, till now I do not see any reason not to support SW. SW is a technical progress instead of a political fight. It should not be affected by others’ emotion or preferences. SW is a technical changes of bitcoin’s the core codes.
If political fight in the bitcoin community results in joint pressure mounting to us, I would say this is not the situation we want to see. We need to make decisions based on the pros and cons of the SW, and on the consensus of the Core’s team members as Core’s members are all excellent programmers. These coders spent a lot of time considering the situation to explore the best scaling solution to fix problems that most of the ordinary people feel hard to understand. If others’ pressure makes us unable to run SW or we press others to run SW, the situation will be bad. I think every should make decisions based on the pros and cons of technicals.
Currently there are many rumors and misgiving within Chinese community. Many people are maligning SW. Like some people are claiming Core will change the POW into PoS; SW is poison; SW is not onchain scaling, or the lighting network will carve up miners’ benefits…all of these are rumors without any source. SW is indeed onchain scaling. Except BU, no developer or engineer would say SW is not onchain sacling.
Q: Won’t BTCC follow the 2015 Beijing Pool Declaration and 2016 Hong Kong Consensus anymore?
A: This seems to be a question of common concerns. I would like to reply in details. Wish it can be clearer for all.
For 2015 Beijng Mining Pool Declaration, there is a long story behind it. You can’t say what happed a year ago equally applies in today’s situation as both internet world and crypto area are evolving fast. The Consensus was actually response to Bitcoin XT, when Gavin Andresen and Mike Hearn firstly incited political fight within bitcoin community which has been witnessed by many mining pools.
At that time. Mike and Gavin tried to contact us quite frequently. They lobbied us and wanted us to use their Bitcoin XT. They said it can scale the blocksize into a 20MB one. They said the block was going to be full and actions must be taken. It’s until now that we are aware that it’s natural for the block to be full. If there is no full block, then there is no profits for the miners. The block space must maintain its scarcity to be valuable. But at that time we were not familiar with technical stuff and didn’t know how capable the Mike and Gavin were. We just knew 20MB was really bigger than 1MB and many other mining pools also felt the need to act so we were also a bit worried. But after some consideration, we believe to have 8MB block size was rather safe. To scale to 8 MB is referred to the Bitcoin XT’s plan of scaling to 20MB. We even didn’t intend to scale to 8MB blocksize. After the Beijing conference, Bitcoin XT distorted our intention by saying that our roadmap is to scale from 8MB to 8GB size. Many mining pools felt they were betrayed.
I don’t think that anyone should be required to conform to the 2015 Beijing Mining Pool Consensus. If it’s a must for everyone to conform to it, then BU should not have gained any support since we just need to scale to 8MB.
For 2016 Hong Kong consensus, it was actually the response to Bitcoin Classic. Bitcoin Classics misled us by saying that all people were supportive of them. Actually everyone at that time believed other people all support Bitcoin Classics so it turned out all people were for Bitcoin Classics. In was in the context that we held that Hong Kong Conference. The consensus stated that Core would write hard-fork codes. So many people thought it was an agreement between BTCC and Core. But actually the consensus was a response for Bitcoin Classic. There were 5 Core members at the site and they signed the consensus. But Bitcoin Core is neither a company nor an organization. It’s only some individuals and companies who support the development of Bitcoin Core. No one can compel Bitcoin Core to do anything and Core will not compel others to do anything. either. This is just the feature of bitcoin. Bitcoin is alive. It’s not a company which can post something on its official site. Likely, Bitcoin Core’s software will not update automatically. (Apple and Microsoft will send you a new version and you have to update). The update of Bitcoin Core is out of your free choices and you can also downgrade the system.
In fact, there are others things in Hong Kong consensus that have not been followed like Core hasn’t completed the development of SW in time. But this just proved their prudence. They will not accept a SW without thorough and sound tests. We have made some mistakes during the Hong Kong Consensus period. We were not familiar with the development of bitcoins. We have kept on learning and improving these years.
Actually Core team indeed has written the hard-fork codes which are published in BIP draft. To seem please find:
In the conference in San Francisco this summer, Core has displayed these codes but the community didn’t give many responses. Core members are trying their best to write code and the process is continuing. They can’t compel the Core to publish the hard-fork publicly as it requires the consensus within the whole Core members. There is no leader in Core.
Core also release 0.13, a version without SW for those who wants the most updated technique but are not willing to use SW. This version contains the most updated techniques like Schnorr signing.
Q: Does BTCC have any contingency plan for any bug which has been discussed on reddit?
Reddit is only a platform for people to share news or discuss anything. The so-called bug discussed on /btc are only the random guess by those who do not know technical stuff.
If you really want to discuss bug issues of SW, please subscribe Bitcoin Core’s email and go to their IRC chatting room. That’s where bug issue should be discussed effectively. Core has all of the communication records of Slack, IRC and subscription list published on the internet, though people won’t go there and see. People like to go to reddit. Reddit is not for technical discussion. It’s for…catfight. These so-called bugs have already been discussed between core members. It is because of these discussions of bugs’ elimination and tests that SW has come out later than expected, Core wants to provide reliable and bug-free codes to support its 11 billion USD worth industry of bitcoin.
Now we look at BU, it hasn’t had many test reports. Actually Core has reported bugs of BU and BU didn’t give any response.
Activity of BU on GitHub Imgur
Activity of Core Imgur
Core has done many tests and they even found bugs of library used by C++.
Q: Dose BTTC support that 1M blocksize should remain so permanently or believe it should be scaled at a proper time in the future?
It is a misunderstanding commonly seen in Chinese community that Core wants the block size to remain 1MB forever.
Core’s road map is just hard fork. But optimization should proceed the hard-fork. Core never said they will hold IMB block size permanently. We don’t want a block with only 1MB size, either. But If bitcoin doesn’t possess the feature of decentralization, then bitcoin is useless. It would be something like a database. Thus the smaller the blocksize is, the better bitcoin is as everyone can run it. You can’t just take care of yourself. A hard disk may be extremely expensive for the poor people. Since those who boast bigger size do not represent all the community, what we could do is to lower the threshold as possibly as we can.
Many people may never involve themselves in Ethereum community. We wanted to run our ETC mining pool but we have encountered many problems only because the block size is too big. You can’t only envision inserting the blocksize in a disk without considering communication, synchronization and orphanage rate. Scaling is not that easy. What many people do not understand is that scaling shouldn’t be done without due consideration. If we put all the date from google and YouTube in everyone’s computer like ledgers of blockchain, then to double the data of Google and YouTube means to double the data of everyone. This will lead to an increasing pressure of the whole network. You have to pay the price for scaling. Those who think the costs are nothing for them simply can not represent everyone.
SW indeed will scale the blocksize and Core team have some techniques for omptimization like the Schnorr signing. Schnorr can compress the transactions of 16MB into a 1MB block under perfect condition. Now the theoretical size is to compress 4MB data into a 1MB blocksize. There are many other methods to make 1MB size block size handle more data. But if needed, we can scale the blocksize into 2MB.
Added: Core team is highly transparent. All their meetings are available on the internet. See
Q: Has BTCC Pool’s support of SW gained understanding and support from miners in your pool? In another way, has BTCC pool explained pros and cons of various options? Any relevant explanatory information can be shared to other pools for reference?
A: we have a professional management team for mining pools and we have maintained active communication with them. Last week I just went to Chengdu of Sichuan Province to meet miners there. We have explained the benefits of SW to the miners of Chengdu and they expressed their supportive attitude. BTCC indeed will explain to our miners the pros and cons of different scaling plans. In the meantime, we also provide reference documents on our Weibo and Wechat to miners, traders and bitcoins fans. We invited one Lightening founder to Shanghai for a meeting with friends in Shanghai. Next week (11th NOV), We will also invite some Core members to be in Shanghai to discuss SW with friends present. We have provided the information of Bitcoin, SW and scaling plans to not only miners and but all users of BTCC.
Q: Has BTCC pool done extensive test on 0.13.1 SegWit code? Can you release test report?
A: Sure. Thorough tests need to be done. In early April 2016, Core has contacted China’s miners including BTCC, F2Pool, AntPool BW to test SW on SegNet; In later April our pool has mined the blocks containing SW transactions; In May, mining pools including BW all completed the tests of SegNet and they have mined SW block; in October, BTCC began to test Bitcoin Core 0.13.1 and the improvements of 0.13.1 has begun since; 18th Oct, the vote of SW officially kicks off. Sorry I don’t have test files for you. But till now, judging from the mining pool’s operation, everything is fine.
The AMA is conducted in Chinese.
Knowing that this AMA really matters for the both Chinese and Western community to know the ideas and thoughts of others, we have tried our best to keep the original meaning and tones in plain English.
To see the original Chinese AMA text,
Please first sign in on , the international site of 8tbc, and then go directly to the thread:
Tune In for more fist hand information on CN community.
submitted by 8btccom to Bitcoin [link] [comments]

Core/Blockstream is living in a fantasy world. In the real world everyone knows (1) our hardware can support 4-8 MB (even with the Great Firewall), and (2) hard forks are cleaner than soft forks. Core/Blockstream refuses to offer either of these things. Other implementations (eg: BU) can offer both.

Core/Blockstream is living in a fantasy world. In the real world everyone knows (1) our hardware can support 4-8 MB (even with the Great Firewall), and (2) hard forks are cleaner than soft forks. Core/Blockstream refuses to offer either of these things. Other implementations (eg: BU) can offer both.
It's not even mainly about the blocksize.
There's actually several things that need to be upgraded in Bitcoin right now - malleability, quadratic verification time - in addition to the blocksize which could be 4-8 megs right now as everyone has been saying for years.
The network is suffering congestion, delays and unpredictable delivery this week - because of 1 MB blocks - which is all Core/Blockstream's fault.
Chinese miner Jiang Zhuo'er published a post today where once again we hear that people's hardware and infrastructure would already support 4-8 MB blocks (including the Great Firewall of China) - if only our software could "somehow" be upgraded to suport 4-8 MB blocks.
Bigger blocks would avoid the congestion we're seeing this week - and would probably also cause a much higher price.
The main reason we don't have 4-8 MB blocks right now is Core/Blockstream's fault. (And also, as people are now realizing: it's everyone's fault, for continuing to listen to Core/Blockstream, after all their failures.)
Much more complex changes have been rolled out in other coins, with no problems whatsoever. Code on other projects gets upgraded all the time, and Satoshi expected Bitcoin's code to get upgraded too. But Core/Blockstream don't want to upgrade.
Coins can upgrade as long as they maintain their "meta-rules"
Everyone has a fairly clear intuition of what a coin's "meta-rules" are, and in the case of Bitcoin these include:
Note that "1 MB max blocksize" is not a meta-rule of Bitcoin. It was a temporary anti-spam measure, mentioned nowhere in the original descriptions, and it was supposed to be eliminated long ago.
Blocksizes have always increased, and people intuitively understand that we should get the most we can out of our hardware and infrastructure - which would support 4-8 MB blocks now, if only some dev team would provide that code.
Core/Blockstream, for their own mysterious reasons, refuse to provide that code. But that is their problem - not our problem.
It's not rocket science, and we're not dependent on Core/Blockstream
Much of the "rocket science" of Bitcoin was already done by Satoshi, and further incremental improvements have been added since.
Increasing the blocksize is a relatively simple improvement, and it can be done by many, many other dev teams aside from Core/Blockstream - such as BU, which proposes a novel approach offering configuration settings allowing the market to collaboratively determine the blocksize, evolving over time.
We should also recall that BitPay also proposed another solution, based on a robust statistic using the median of previous blocksizes.
One important characteristic about both these proposals is that they make the blocksize configurable - ie, you don't need to do additional upgrades later. This is a serious disadvantage of SegWit - which is really rather primitive in its proposed blocksize approach - ie, it once-again proposes some "centrally planned", "hard-coded" numbers.
After all the mess of the past few years of debate, "centrally planned hard-coded blocksize numbers" everyone now knows that are ridiculous. But this is what we get from the "experts" at Core/Blockstream.
And meanwhile, once again, this week the network is suffering congestion, delays and unpredictable delivery - because Core/Blockstream are too paralyzed and myopic and arrogant to provide the kind of upgrade we've been asking for.
Instead, they have wimped out and offered merely a "soft fork" with almost no immediate capacity increase at all - in other words, an insulting and messy hack.
This is why Core/Blockstream's SegWit-as-a-spaghetti-code-soft-fork-with-almost-no-immediate-capacity-increase will probably get rejected by the community - because it's too little, too late, and in the wrong package.
Engineering isn't the only consideration
There are considerations involving economics and politics as well, which any Bitcoin dev team must take into account when deciding how to package and deploy the code improvements they offer to users - and on this level, Core/Blockstream has failed miserably.
They have basically ignored the fact that many people are already dependent for their economic livelihood on the $12 billion market cap in the blockchain flowing smoothly.
And they also ignored the fact that people don't like to be patronized / condescended to / dictated to.
Core/Blockstream did not properly take these considerations into account - so if their current SegWit-as-a-spaghetti-code-soft-fork-with-almost-no-immediate-capacity-increase offering gets rejected, then it's all their fault.
Core/Blockstream hates hard forks
Core/Blockstream have an extreme aversion to what they pejoratively call "hard forks" (which Bitcoin Unlimited developer Thomas Zander u/ThomasZander correctly pointed out should be called by the neutral terminology "protocol upgrades").
Core/Blockstream seem to be worried - perhaps rightfully so - that any installation of new software on the network would necessarily constitute "full node referendum" which might dislodge Core/Blockstream from their position as "incumbents". But, again, that's their problem, not ours. Bitcoin was always intended to be upgraded by a "full node referendum" - regardless of whether that might unseat any currently "incumbent" dev team which had failed to offer the best code for the network.
Insisting on "soft forks" and "small blocks" means that Core/Blockstream's will always be inferior.
Core/Blockstream's aversion to "hard forks" (aka "protocol upgrades") will always have horrible consequences for their code quality.
Blockstream is required (by law) to serve their investment team, whose lead investors include legacy "fantasy fiat" finance firms such as AXA
This means that Blockstream is not required (by law) to serve the Bitcoin community - they might, or they might not. And they might, or might not, even tell us what their actual goals are.
Their corporate owners want soft forks (to avoid the possibility of another dev team coming to prominence), and they want small blocks (which they believe will support their proposed off-chain solutions such as LN - which may never even be released, and will probably be centralized if it is ever released).
This simply conflicts with the need of the Bitcoin community. Which is the main reason why Blockstream is probably doomed - they are legally required to not serve their investors, not the Bitcoin community.
If we're installing new code, we might as well do a hard fork
There's around 5,000 - 6,000 nodes on the network. If Core/Blockstream expected 95% of them to upgrade to SegWit-as-a-soft-fork, then with such a high adoption level, they might as well have done it as a much cleaner hard fork anyways. But they didn't - because they don't prioritize our needs, they prioritize the needs of their investors.
So instead of offering an upgrade offering the features we wanted (including on-chain scaling), implemented the way we wanted (as a hard fork) - they offered us everything we didn't want: a messy spaghetti-code soft fork, which doesn't even include the features we've been clamoring about for years (and which the congested network actually needs right now, this week).
Core/Blockstream has betrayed the early promise of SegWit - losing many of its early supporters, including myself
Remember, the main purpose of SegWit was to be a code cleanup / refactoring. And you do not do a code cleanup / refactoring by introducing more spaghetti code just because devs are afraid of "full node referendums" where they might lose "power".
Instead, devs should be honest, and actually serve the needs of community, by giving us the features we want, packaged the way we want them.
As noted in the link in the section title above, I myself was an outspoken supporter championing SegWit on the day when I first the YouTube of Pieter Wuille explaining it at one of the early "Scaling Bitcoin" conferences.
Then I found out that doing it as a soft fork would add unnecessary "spaghetti code" - and I became one of the most outspoken opponents of SegWit.
By the way, it must have been especially humiliating for a talented programmer Pieter Wuille like to have to contort SegWit into the "spaghetti-code soft fork" proposed by a mediocre programmer like Luke-Jr. Another tragic Bitcoin farce brought to you by Blockstream - maybe someday we'll get to hear all the juicy, dreary details.
Dev teams that don't listen to their users... get fired
We told Core/Blockstream time and time again that we're not against SegWit or LN per se - we simply also want to: