Andreas isn't saying anything different ro the argements made on this forum, though


These arguments aren't "special" because "special" Andreas Antonopoolos makes them, they stand on they're own (not unlike Andreas' own comment that "Segwit is good tech regardless of who wrote it", ironically)


Be careful with these "thought leaders", because the more we increase their status, the more danger there is that people will blindly follow people like Andreas when he's suggesting something that's bad for Bitcoin (which he's never done, yet)

FYI everyone:

This story is 2 and a half years old, Tim Draper made these comments in 2014, not in recent 2017

There's nothing stopping either of you from learning how it works, it's sort of crazy to get involved in something like this and let everyone else do the thinking for you. And FYI, Zicadis has zero clue, adding more pools (or more mining hashrate in general) makes negligible difference to the speed that transactions get processed. If you don't know what you're talking about, please, either learn, or be quiet.

All states lie on the autocratic-didactic scale somewhere, and the only way to make that happen is having a violent enforcement class. You just can't get away from it, and suggesting that a system like this can be instituted without defiling the natural rights of whatever amount of people disagree, minority or majority, is wrong, and you are morally unsound to even suggest it.

Property is not theft, top-down state communism is theft. Steal from me, and I will defend my property, you risk the consequences of my defence against you aggressing against me. I don't know why you are suggesting such illiberal and immoral nonsense in a Bitcoin forum, Bitcoin is the one technology of the age that thoroughly defies state power of all stripes.




Here, we agree.

Employee owned co-operative enterprise, which is simply communism or socialism applied in a different context, and called by a different name, has very clear advantages over top-down corporate ownership model, especially for mature markets. But it must be voluntary, not mandated by official violence as you did when you endorsed state communism. And these enterprises must be careful to make sure competitors do not infiltrate their workforce to abuse employee rights against the overall interests of the overall goal of said enterprises.

And remember too that there is an obverse to the advantages of cooperatively owned enterprises; as a structure, it can cause serious problems for enterprises that need alot of  innovation to achieve their aims. If the employees cannot grasp the apparently eccentric vision of one individual, then the freedom to experiment and innovate can be stifled or even destroyed. Allowing company leadership to choose their ownership and decision making model is, therefore, of paramount importance. One size does not fit all.

Okay, with Qubes OS, this is an issue.

/home and /usr/local are the only directories that the VM templates do not refresh in the user VMs that do the actual client work (the templates have strict firewall rules that prevent any network access except a local software update proxy VM).

This means that user VMs derived from their template VMs do not pick up any changes to the filesystem made to the /home and /usr/local directories and below. That means re-creating the user VMs every time a new Armory package is installed (I've tested this out). If the bitcoin blockchain or armory databases are installed on the actual VM disk, which is the most convenient (and also the default) option, then they must be copied off the old VM and onto the new. It's serious rigamarole, in short.

What can be done here? Basically, anywhere but /usr/local will eliminate this problem for Qubes users.

Yet again: what scaling debate?

Segwit only lays the groundwork for scaling, but without the subsequent changes that Segwit will permit, Segwit does nothing to change scale of the Bitcoin network's operation.

The bigger blocks "solutions" solve nothing, and certainly cannot be appropriately described as anything to do with scaling the Bitcoin network. Bigger blocks add capacity, no different to Segwit standalone, but capacity increases are by definition not changes to scale.


Any genuine scaling solutions are going to be taking place in the future, after all this Segwit and big blocks nonsense is a disappearingly faint memory.


Uh, anyone home at coindesk.com?

According to the thread title, this article was published on 26th April 2017 (which is tomorrow), yet the above sentence appears to have been written about 2 months ago, when Segwit signalling actually was stalling. Whereas in the actual observable present (which coindesk.com "journalists" appear to be incapable of achieving), Segwit signalling for Bitcoin has risen steadily for the past 6-8 weeks, from 25% to 33%.

Do some journalism if you want to be referred to as journalists or news, coindesk

Have fun waving your weenie. On the internet.

Tell us who these emasculated "startups" are, Cathy, I will be making sure not to use their business. What sort of business wants to actively seek breaking the use-case for the technology that interested their prospective clients to begin with? Private money is private, apparently even the public sector education appointee in this newspiece knows this, while the so-called businesses do not.

Ha! Can't believe I didn't think of that, must have been that. I am this year's bitcointalk April Fool

If we're taking that 100% literally, then that would be true, Segwit isn't a scaling solution on it's own.

The versionbits BIP9 that's part of the Segwit fork will kind of help (so that more than one soft-fork can be signaled at once, only one can be signaled and/or activated concurrrently with the present soft forking mechanism).

And of course, Segwit will allow for a range of 2nd layer networks on top of the Bitcoin blockchain, of which Lightning is only one (just the one most talked about).


But Segwit does nothing for scaling the network, it does increase capacity, but capacity and scaling are not the same concepts.


You're right and wrong about detractors denouncing Segwit's efficacy, it will of course happen, but as I mentioned above, it's actually already started to happen months ago (the claim was that it would take years to move to move every unspent BTC output to Segwit addresses, not the months that it will more likely take) You can't really give the heads-up for something that's already happened, sadly

1. We're not talking about hypothetical 0.25MB base blocks anyway, we can throw that out instantly

2. I got into a conversation with Franky about this (one of the last I had with the people who man that account). If every single transaction in every block was from a pre-Segwit address to a Segwit address, it would only take 6 weeks to move it all across with today's UTXO set.


So realistically, it might take a few months, as not everyone will try to switch to Segwit addresses at once, they're going to want value for money. But as more people moved BTC to Segwit addresses, they'd start using the extra 3MB Segwit blocks straight away, gradually taking pressure off the 1MB base blocks used to switch over to Segwit address types. Sure, it's another compromise, but it will be a worthwhile 2-6 months of increased fee pressure, and it would be the reality no matter which way segregated witness was implemented. I certainly won't need to move my funds straight away, so not every single user will be exerting this effect on the blockspace simultaneously.

There's nothing to check, you're just saying "it's possible" without giving reasons why.

It's possible to change the blocksize to 8MB, that doesn't make it desirable or sustainable, or at least not today. If 97.5% of the world had FTTP fibre-optic internet connections and cat 12 LTE 4G phones, then massive blocks might work. But saying "because" is not an argument.

When you're wrong, or putting words in my mouth, I say it, how could I do anything else? You (or anyone else) has never had to call me out for arguing using underhand tactics, because I simply don't do it.

You're saying that calling you out when you claim I've said something I didn't is all I ever do. This is categorically no different to your behaviour in those previous exchanges between us; because you can't make your points fairly, you choose to come at me with personal sleights that have no merit.

You have no shame, basically. You say something you know I will agree with, just so you can paint an exaggerated caricature of my comportment in debate, reactions that are forced on me by the bad sportsmanship of people like you.



And, I'm not sure I totally follow your "less space for vanillas transactions" remark.

If it's Segwit by hard fork, then there are by definition 2 chains, the same block space exists for the 1MB fork as did before in that circumstance. The 4MB Segwit chain could arguably have less space for P2PKH & P2SH transactions (aka the "vanilla" types, as you call them), but that balance is to be determined by the market price of transaction confirms, just like now.

One could make the same argument for the price/resource differential between the P2PKH and P2SH transaction types we can already use with Bitcoin today; P2SH is inherently more expensive, as it uses more space even for the simplest P2SH transaction. Are P2SH transactions "causing backlogs to become longer until everyone had the chance to update"? People that only wanted to use P2PKH could've just failed to update to the version of Bitcoin that introduced P2SH, but in practice, they accepted the compromise of having to compete with higher fees for the additional blockspace with P2SH transactions, presumably because they wanted the new features and bugfixes that came with new Bitcoin software that inevitably included P2SH.

Using Segwit transactions as a parallel example, the native P2WPKH and P2WSH formats (i.e. not the initial implementation that nests them inside a P2SH script) will be slightly smaller than their vanilla PKH and SH types anyway, so it's really difficult to see what you're getting at. What are you getting at?

No, I more or less agree with you.

The only "messy" aspect of a 0.25 MB/ 0.75 MB Segwit would've been that it couldn't be done without a hard fork, i.e. both miners and regular nodes would need to upgrade in a very coordinated and holistic manner, which is quite like what you're saying anyway, I just choose to add different details presented a little differently. And I agree about your 1/3 comments too, you should make it clear that the necessary hard fork to implement 0.25/0.75 MB Segwit is the reason why the 1/3 MB soft-fork solution is smoother on the user experience (no choice between 2 chains, as you say).

Nope, Segwit does what I don't want in terms of scaling, Segwit just adds more transaction capacity by adding more blockspace. I implied nothing different, you're straw-manning (and it's boring)

Segwit lays the foundation, the capability to scale off-chain. It's got zero relationship to on-chain scaling, it increases capacity using the Bitcoin network's resources at the same scale as we have right now (i.e. 1MB block holds ~ 2000 transactions). A factor of 4 increase in the amount of transactions using a factor of 4 increase in the blocksize is not scaling (i.e. 4MB Segwit blocks hold ~ 8000 transactions), it needs to be a factor of > x increase in transactions using a factor of x blocksize to actually scale up on-chain capacity, and Segwit doesn't do that. At all. And I have never said that it did.

You're a disgraceful liar jonald

There is no aspect of the Lightning network (i.e. for quick everyday cups of coffee) that will be either permitted by nodes or overseen by any government, you must be out of your mind to make such false assertions.

The proof is very easy to find, check out this thread: WORKING Lightning Node Network (LNN) on TESTNET, feel free to join.

Notice how it says "feel free to join". That's because there is no permission, or oversight, it's actually more private than on-chain transactions, as only the channel participants know about the transactions. You know how this works, you were even discussing the technical details of Lightning a week or two ago, you cannot possibly pretend now that you don't understand what you knew perfectly well only a week ago, unless you're getting dementia. You're desperate, and it shows rather badly.



Where is your kitchen table math for these unproven assertions? Considering you're just straight making things up in your previous diatribe about Lightning, I don't see why anyone should take your unbacked assertions about math or logic even faintly seriously

Indeed, and you'll notice that I concentrated on scaling vs non-scaling, no mention or allusion to Segwit in any way, shape or form..


You're part of the false narrative, classicsucks. You actually speak as though you believe that changing the transaction capacity without changing how that scales the Bitcoin network is somehow the same thing as scaling the network.

And all you can do is the same thing all non-scalers do: tell obvious troll-ish lies about what I said (nothing to do with Segwit and all about scaling vs non-scaling), and throw mud at the Core project.


You know who's not listening, in the face of reason, and simultaneously presenting non-reasoned sophistry as technical arguments? You and the "blocksize is the only thing that exists, sorry, can't hear you, fingers-in-ears" brigade.

@Simon Belmond

The settings goatpig recommended are tailored for low-RAM low-CPU machines, but there are no guarantees. Try it, and you will see. Glad to hear you have a working Armory setup now regardless.

@goatpig, did you change the location of the Armory installation for 0.96? I've tried the 0.95.99.3 .deb package, but I'm getting an absence of installation at /usr/lib/ (even the directory /usr/lib/armory isn't created, /usr/local/armory & /usr/local/armorydb are created). Installation is suspiciously quick also, is there some error in the install package?

You need to use very precise language for technical discussions. Not only is your language not very precise, but you're also repeating the broad points you already made (without taking the counter-points into account), and providing no reasoning, either

It's not a scaling debate

If it was, everyone from all positions would be arguing about scaling, but they're not.



I would like to see genuine discussions on scaling taking place, and frequently talk about actual scaling paradigms for Bitcoin's blockchain to grow without endangering it's decentralisation (which is a huge part of what makes Bitcoin so powerful, and hence, valuable).

But loud relentless opposition to scaling is always drowned out by people pushing for capacity increases that do not scale, sacrificing decentralisation is not a problem for these people. And these same people falsely state that increasing the transaction capacity at the same scale actually is changing the scale, it's mind-blowingly foolish talk.



It's best just to face the facts: a very determined group of people have infiltrated Bitcoin's culture, and are trying incredibly hard to wear everyone down with over 2 years of constant repetition of non-factual presentations on how to improve Bitcoin's transaction capacity, and they will never stop and always ignore genuine reasoning in favour of every trick they can possibly come up with. And up to now, their proposals (XT, Classic and BU) have been unanimously rejected, every single time (one hilarious trick is to constantly repeat the falsehood that everyone in Bitcoin is in favour of the latest on-chain non-scaling proposal, despite the overwhelming majority of real Bitcoin nodes on the Bitcoin network rejecting all these proposals)


So, if one group of people aggressively and unrelentingly push for x, when their idea is actually NOT-x, what are they really arguing for?

The proposals of the on-chain non-scaling contingent always involve hard-forking both the software code and the blockchain itself to a completely different set of programmers than those who currently develop Bitcoin. This group don't just want to make the Bitcoin network more centralised with their plans, they also want to change the leadership. It's been suggested to them on many, many occasions that they could try their ideas on a new and separate cryptocurrency. They consistently reject this, claiming to already represent the "real" Bitcoin (despite having nothing but assertions to this claim, and despite pushing for taking control and never getting the support to do it).