I'm Marshall Long aka 挖矿王子 - Partner & CTO of FinalHash, LLC and a True Bitcoin OG

[Marshall]

3. BTC is not huge in China. Simply because they have great ways to make P2P payments already IMHO. Alipay, WeXIN Pay, etc.

Neither of those are p2p payments. All of them involve banks and companies.

I really hope that the majority of the miners are more intelligent and better informed than this individual, otherwise bitcoin's future is less bright.

Also, I really hope that in the end Satoshi's vision works out and individual bad apples won't be able to ruin the "experiment".

It is people like you that make people like me hate working in Bitcoin.
That aside.
Yes they are not REALLY p2p. However, they work flawlessly and have ridiculously low fees. In china, i can send a wire transfer domestically for $0.25. At these levels of fees, it really starts to seem like a p2p solution that is 100% mobile based.

[Marshall]

Thanks for doing the ama.

I have recently tried aquiring ASIC chips for building my own mining rig to sell to consumers. However every current gen manufacerer will not sell chips to third parties. Doesn't this mean that mining is already centralized? Since the chip makers can effectively lock out new competition and inevitablely the existing competition will come down to fewer and fewer that are able to keep up.

Not being able to get bare chips is preventing us from creating an alternative approach to mining that would allow for profitable decentralization. Does this mean we will have to spin our own silicon if we don't take the datacenter approach and buy miners from another company?

Getting chips is in fact hard for most folks. Email me marshall@finalhash.com and I would be happy to facilitate this for you. They don't sell chips to folks they do not know well. But happy to help you out.

[Marshall]

1. We as miners would never switch the XT. All biases aside, switching our pool servers over would be a massive waste of money.

Sorry but that's BS.

XT is a fork of bitcoin core, There is basically 0 difference whether the fork happen or not.

The downtime would be basically non-existent if the migration is planned and executed right, so I'm curious what "waste of money" you are referring to?

Generally, any change to the pool server is frowned upon. We don't know if we misstepped and broke something or whatever. This has nothing to do with XT or not. As per my disclaimer, ALL BIASES ASIDE. ANY CHANGE TO A POOL SERVER GETS THE ATTITUDE "if it ain't broke, don't fix it." Unless XT can provide a ridiculous advantage (which right now it doesn't make us more $$) we won't take the time and risk our devs fat fingering us into a missed block.

[Marshall]

Texan programmer mining Bitcoin in China. Quite the unusual combination.

How did you end up in China?

A series of beautiful events.

[imaginary_username]

Sorry but that's BS.

XT is a fork of bitcoin core, There is basically 0 difference whether the fork happen or not.

The downtime would be basically non-existent if the migration is planned and executed right, so I'm curious what "waste of money" you are referring to?

Generally, any change to the pool server is frowned upon. We don't know if we misstepped and broke something or whatever. This has nothing to do with XT or not. As per my disclaimer, ALL BIASES ASIDE. ANY CHANGE TO A POOL SERVER GETS THE ATTITUDE "if it ain't broke, don't fix it." Unless XT can provide a ridiculous advantage (which right now it doesn't make us more $$) we won't take the time and risk our devs fat fingering us into a missed block.

Wait, how do you upgrade your Core version then, if any change to the pool server/software is frowned upon (i.e. 0.9 -> 0.10 -> 0.11 etc)? Is that what caused the F2Pool et. al. soft fork fiasco back in BIP66 days?

XT aside, this seems like a major problem with how pools are done now - if upgrade paths are perilous, soft forks will cause massive problems every time it's done and hard forks will never be done at all. Is the pool setups not modular (i.e. the core can be switched out easily) at all?

[jtoomim]

Generally, any change to the pool server is frowned upon. We don't know if we misstepped and broke something or whatever.

What do you think about setting up something on testnet to mirror your mainnet configuration? It would take some work to port stuff like Matt's relay network over to testnet and to get the performance of testnet up to the level that mainnet already has, since there's no financial incentive to make sure it's working.

[Marshall]

Generally, any change to the pool server is frowned upon. We don't know if we misstepped and broke something or whatever. This has nothing to do with XT or not. As per my disclaimer, ALL BIASES ASIDE. ANY CHANGE TO A POOL SERVER GETS THE ATTITUDE "if it ain't broke, don't fix it." Unless XT can provide a ridiculous advantage (which right now it doesn't make us more $$) we won't take the time and risk our devs fat fingering us into a missed block.

Wait, how do you upgrade your Core version then, if any change to the pool server/software is frowned upon (i.e. 0.9 -> 0.10 -> 0.11 etc)? Is that what caused the F2Pool et. al. soft fork fiasco back in BIP66 days?

XT aside, this seems like a major problem with how pools are done now - if upgrade paths are perilous, soft forks will cause massive problems every time it's done and hard forks will never be done at all. Is the pool setups not modular (i.e. the core can be switched out easily) at all?

In fact we dont upgrade if we don't have to.

[jtoomim]

Marshall, do you think that scaling the Bitcoin network to handle much larger blocks (e.g. >= 8 MB) is

1. A desirable goal that is unattainable in China with current infrastructure,
2. A desirable goal that is unattainable anywhere,
3. A desirable goal that is attainable in China,
4. An undesirable goal, or
5. [fill in the blank]

[imaginary_username]

Wait, how do you upgrade your Core version then, if any change to the pool server/software is frowned upon (i.e. 0.9 -> 0.10 -> 0.11 etc)? Is that what caused the F2Pool et. al. soft fork fiasco back in BIP66 days?

XT aside, this seems like a major problem with how pools are done now - if upgrade paths are perilous, soft forks will cause massive problems every time it's done and hard forks will never be done at all. Is the pool setups not modular (i.e. the core can be switched out easily) at all?

In fact we dont upgrade if we don't have to.

Uh... kind of expected, but still unsettling.

What do you think about CheckLockTimeVerify (CLTV), which currently has fairly broad consensus at both the Core camp and the XT camp? It's a soft fork, so technically speaking even if it gains flag-consensus, you can just flag-to-follow and don't actually have to enforce it; but if there's no actual enforcement it'll fall apart.

[cypherdoc]

Marshall,

regarding your Chinese mine, how do you view the Relay Network, which as i understand it exists mostly outside of China (i know there's been talk of putting a node within China but the way you talk it doesn't sound like it's up yet)? does it make miners outside of China more competitive to your China mine b/c of your bandwidth issues? if so, is this why you SPV mine when a full block comes along or is there some other reason related to block size?

[c7d1d28]

Hello,

yesterday I noticed an IP on my bitcoin node which was using like 6 connection slots and each had around 1 Gbyte outbound traffic.
I googled the IP and found this tweet: https://twitter.com/petertoddbtc/status ... 9872830464
with an answer from @finalhash which indicates this could be something from you?

If this is from you, can you explain what "btcwire" does and why it needs multiple slots? You can use up as many traffic
as you want on my node, if you use only 1 connection slot that is. Because of that I have iptables blocked that ip for now,
but I am polite and reject with icmp-host-prohibited

[helloworld]

Neither of those are p2p payments. All of them involve banks and companies.

I really hope that the majority of the miners are more intelligent and better informed than this individual, otherwise bitcoin's future is less bright.

Also, I really hope that in the end Satoshi's vision works out and individual bad apples won't be able to ruin the "experiment".

It is people like you that make people like me hate working in Bitcoin.
That aside.
Yes they are not REALLY p2p. However, they work flawlessly and have ridiculously low fees. In china, i can send a wire transfer domestically for $0.25. At these levels of fees, it really starts to seem like a p2p solution that is 100% mobile based.

Do you mean you hate people who do not bullshit?

That's even more funny, because I'm not the one who has no idea what he is talking about in this debate.

Based on your responses it's evident that you are where you are because of pure luck not because of merit.

I still stand behind my opinion and I hope that malicious actors like you cannot affect the experiement negatively on the long run.

[Marshall]

Hello,

yesterday I noticed an IP on my bitcoin node which was using like 6 connection slots and each had around 1 Gbyte outbound traffic.
I googled the IP and found this tweet: https://twitter.com/petertoddbtc/status ... 9872830464
with an answer from @finalhash which indicates this could be something from you?

If this is from you, can you explain what "btcwire" does and why it needs multiple slots? You can use up as many traffic
as you want on my node, if you use only 1 connection slot that is. Because of that I have iptables blocked that ip for now,
but I am polite and reject with icmp-host-prohibited

No it wasn't me. I just love giving Petey a hard time hahaha. But an IP Table should fix it for you for sure.

[Marshall]

Marshall, do you think that scaling the Bitcoin network to handle much larger blocks (e.g. >= 8 MB) is

1. A desirable goal that is unattainable in China with current infrastructure,
2. A desirable goal that is unattainable anywhere,
3. A desirable goal that is attainable in China,
4. An undesirable goal, or
5. [fill in the blank]

Well, honestly the latency issues won't be an issue for long IMHO. China Unicom and some others are pushing hard on this. With 1.3B people it just gets harder. With current infrastructure i think over 8MB right now doesn't make sense. But soon it will.

In reality, yes i think a combination of things like bigger blocks and other solutions together is needed. I like the idea of lightning for sure too.

[arnoudk]

Hi Marshall. Thanks for doing this AMA. I'm not sure if it is still ongoing, but I'll try to get my question in anyway!

You said (I'm paraphrasing) that you would like to minimize your exposure to risk, and thus not upgrade if you don't absolutely have to. I can understand that. How does that relate to BIP101 (or Bitcoin XT, but going by your responses you would prefer the big block patch)? If miners and exchanges are switching over to BIP101 you would be at risk of mining blocks on the shortest chain. The network forks only with >75% of participants on it. How are you minimizing risk by not adding BIP101? (Maybe not now, but when other miners and exchanges and merchants do this)? To me, minimizing risk in this scenario would be to run the code that can immediately take advantage of both possible scenarios and not code that breaks in one scenario?

Currently, it would appear you have all the time to rigorously test the system and it's stability with the BIP101 patch applied. Going by your comments, you would much rather prefer that to a hastily enforced change that could happen if the network switches over.

(For this question, you can read BIP101 to mean any bigger block solution that has an implementation in code).

Assuming that you prefer a solution other than BIP101 - what would be your motivation? I believe other BIPs for larger blocks are technically much more difficult and thus increase your risk. They have no code yet, which increases your risk. They have not been tested as thoroughly yet, which increases your risk. Yet you seem to prefer BIP100, which by my understanding is higher risk (although it does give miners more power). How do you consolidate your desire to avert risk with the desire to support a higher-risk bigger block solution?

Thanks!

[jtoomim]

Well, honestly the latency issues won't be an issue for long IMHO. China Unicom and some others are pushing hard on this. With 1.3B people it just gets harder. With current infrastructure i think over 8MB right now doesn't make sense. But soon it will.

In reality, yes i think a combination of things like bigger blocks and other solutions together is needed. I like the idea of lightning for sure too.

When you say "latency issues", do you mean ping times, or do you mean the latency from sending a large amount of traffic? Or do you mean total system latency, which would include computation time (e.g. TestBlockValidity() and CreateNewBlock())?

Do you think that running your full node/poolserver in the same building (or even the same country) as your miners is needed or desirable for latency? Have you thought of using ckpool's proxy function to pass through the Great Firewall and get to a high-bandwidth trunk line in a bandwidth-efficient manner? (You're using ckpool, right?)

Yeah, I think Lightning is really cool too. I hope it actually gets implemented and works as well as the whitepaper suggests. We probably won't know what shortcomings it has until after it has been implemented. Do you think it's going to be the solution to all of our capacity problems?

[Lastrock625]

Marshall,

when are youre developers going to finish inplementing Paycoin whitepaper?

Also still waiting for Vaultbrakers you bot me from MAT.

Love you pumpkin.

Homero.

[Diogenes]

What is your affiliation with Cryptsy?