No real rush, like I said, I'd just prefer to start using compressed keys for everyone's sake. On that note, will compressed keys become the default key chain in the new wallets? And nested P2WPKH subsequently? I'm hardly expecting a no, I'm just wondering if you think that might cause an issue I'm not seeing.


A mild Bug in 0.96


The scroll bar magic (that traverses super long balance lists) becomes stuck if I try to get beyond a certain proportion of the balance entries.

I'm just clicking, holding the click, and dragging the bar all the way to the base of the bar's range. Releasing the click and re-dragging to the base of the bar gets me to the actual definitively oldest tx, but trying to do the same trick on the way back to the top doesn't work; the magic itself begins to loop to the sticking point, as if that's the most recent transaction. Simply using the 'Goto' button's 'Top' hyperlink style thingy remedies this bottom->top sticking.

Edit - A separate issue is possibly triggered by this; after provoking this bug, when a new block comes in, Armory sends the tx entry highlight/selection bar ~ 60 tx entries lower down the list, where it would ordinarily remain scrolled to the top and de-highlight the entry that was highlighted before the block arrived. If that makes sense!



The server=1/RPC cookie issue

If the absence of server=1 can be detected, why not get Armory to produce an Error dialog box to tell the user how to deal with the issue? As I said, there'll be infinity threads about this if it's not handled at the software end somehow

You're a dirty little exaggerater when you have no real argument, huh

I said nothing of the sort. SOME of the miners are behaving irresponsibly as they are not respecting what their actual responsibilities are. Bitcoin 13.1 was the Segwit soft fork implementation only, and the users overwhelmingly demonstrated they are ready for it and supportive of it, even now 13.1 is actually more numerous on the network than the release that came immediately after it.


DON"T YOU DARE SUGGEST I'M DOING SOMETHING WRONG BY POINTING THAT OUT. You're a disgrace, the sort of fool who will not back down in an argument beacuse of your precious little ego.

You're wrong, you're suggesting something staggeringly foolish and I will not be brow-beaten by someone who cannot swallow their misplaced pride on such an important issue




Dedicating a huge thread, labelled as BIP 102, but is actually BIP 102 on Schwarzenegger doses of steroids SURE AS HELL DOES LOOK LIKE SOMEONE PUSHING BIGGER BLOCKS AT ANY COST.

If you're not dismissing on-chain scaling improvements in favour of just flat-out increasing the resources the Bitcoin network needs to run, then why are you:

• Dismissing on-chain scaling improvements
• Heavily promoting increases in the resources the Bitcoin network needs to run

Well, you could've fooled me.



NO.

I don't want to hear another word from you or anyone else about blocksizes until you can demonstrate that you've investigated anything else but, and that you understand it's the worst and most dangerous way to increase capacity, and most of all that it DOES NOT CONSTITUTE A SCALING PARADIGM AT ALL. There's not much point in trying to argue otherwise, it's an incontrovertible fact.

Any news on this?

DANGEROUS words, gentlemen.

Andreas can get things wrong just like anyone else. The fact that he's being level headed now DOES NOT make it sensible to start anointing him as the font of all wisdom in Bitcoin, what happens if/when he begins to advocate something very destructive?



There are no Bitcoin gods, there are only ideas to be REASONED OVER.

Authority is not the truth, truth is the authority.

Hmmm, can't help but agree. I say it though as I'm anticipating constant creation of new & potentially long threads where this issue is troubleshooted, until round about the end of time itself

I have. Have you?

I don't think you understand the politics here: the inconsistencies in the position of the miners blocking Segwit/promoting BU are obvious; they're saying "but we want big blocks!" when they're being offered big blocks. It's a bit like the way you're arguing, really

The obstructionist miners are doing so to add to the conflict, they're not interested in being constructive, it's incredibly transparent that's their intention, to those that aren't completely naive of course



gmaxwell posted on Bitcointalk about the tx encoding efficiency hard fork a few weeks ago. He mentioned a factor of improvement, why aren't you motivated to find out for yourself what it is, instead of taking a demonstrably controversial, fruitless and very naive route?

Again, if you're really interested in actual scaling paradigms and not dangerous non-scaling resource use increases, you would be sufficiently motivated to look for yourself.

I've read it and don't need to read it again. You sound interested, so what's the problem? Are you interested and motivated, or not?



And AGAIN please, respond to the actually argument I'm making, not derailing back into arguments defending x=y linear growth in blocksize. Using actual scaling paradigms that multiply the utility of EXISTING CAPACITY is far more valuable and sensible than your idea of adding extra burden to the capacity at the same scale.

Yep, exactly the symptoms I experienced (cookie error) before achow101 set it straight. Needs to be in the 0.96 release notes, and if possible written to bitcoin.conf automatically (IMO)

Liar



People had the opportunity to accept 2MB 3 times (BIP 102, XT, Classic).

You supported it, all 3 times, jumping from one bandwagon to the next with zero dignity.


All 3 times, no-one in Bitcoin was the slightest bit interested, and the proposed forks withered and died.


But you were here, along with the other havoc-wreaking trolls, trying to work "2MB" into the conversation any opportunity you got, 3, 4, 5 or even 6 repetitions in one post.




It was like the bit in "Being John Malkovich" when Malkovich takes the ride into his own mind, except you were echo-chambering:


"2MB, 2MB? 2 MMMMB! 2MB. 2MB
2MB. 2MB. 2MB, 2MB? 2MB.         2MB!!!!!!


2MB??


2MB!!!!!!!!!!!!!!!!!!!!"

You're shifting the argument, and it's dishonest

My point is not to argue the finer details of whether this scenario or that scenario is sufficiently problematic to cause impact X on the network.

What I'm saying (and which you did not address) more broadly is that there are multiple possible situations like the scenario I presented that are becoming more likely because of the rising trend of polarised diplomatic relationships between strategically important states, all over the world.


Lie to us, tell us that polarised diplomacy between major states doesn't carry the serious threat of conflicts that could disrupt the internet very badly




I am not sure how much can be achieved using those on-chain scaling methods, but that wasn't the point. I'm proving that different ways to scale exist that do not carry the dangers that blocksize increases do, and that also constitute actual scaling, instead of just using more resources at the same scale.


Again: the sensible engineering approach for a peer-to-peer network is to use sensible margins of safety and precaution, IN PARTICULAR when it comes to the resources the network needs to operate



Prove it.

I'm suggesting, without stating opinions as fact, that Segwit's 4MB IS the compromise solution. You're just using circular reasoning, yet again.




You're not getting the broader point here: there are several ways (and likely several more we haven't thought of) that could be employed to get that kind of transaction density with 4MB Segwit blocks, bigger than that is unnecessary when there are other options.

You're just desperate to keep the conversation on the track of "bigger blocks = only method to increase tx rate possible", when it's demonstrably provable that it's the WORST WAY TO ACHIEVE THAT because it carries the MOST SIGNIFICANT RISKS WHEN DEALING WITH PEER TO PEER NETWORKS.



Please, respond to the actually argument I'm making, not derailing back into defending x=y linear growth in blocksize. It's indefensible, when the same rate of growth could be achieved a less dangerous way, using actual scaling paradigms that multiply the utility of EXISTING CAPACITY, not adding extra burden to the capacity at the same scale.

Indeed.


They have no authority, they have only violent enforcers of their arbitrary decrees, no different to the original fascistas who beat non-compliant serfs with bundles of sticks.

"I'll beat the shit out of and steal from you if you disagree" is not authority, it's tyranny.

So if you're the "impartial voice of reason", as you frequently cast yourself, you're presumably waiting for... what? exactly? Before you tell us your reasonable-middle-ground position? Because you never have one.

Tell us what you think, because it's a little pointless just to keep stepping in deriding everyone like you're somehow above it all, and yet so aloof that you've got nothing that's actually pertinent or useful to add either

You must be joking jonald, literal IRL ROFLMAO


"Least controversial"? You cannot be serious

Well, Segwit opens that door, but it doesn't do it on it's own.

Segwit is bigger blocks, on-chain scaling. But, because signature malleability isn't possible with Segwit transactions, it enables much improved 2nd layer solutions to work far better than they otherwise could (2nd layers have been possible since BIP 65 and BIP 66 soft forks activated last year).


Segwit arguably does change transaction space efficiency, but with a trade off: it make a new pruning mode possible, as only the signatures from newer blocks are needed to keep a full node running on the right blockchain. But that's a centralisation risk in it's own right, as then only miners need the signatures to run, users can switch to sig pruning mode. It saves the regular user 75% of their hard disk space, but I'm not sure its worth it. I'll be keeping the signatures (aka witness mode) on my node, and I hope the devs see sense to keep witness mode on as the default.

The main point is that bigger blocks is NOT changing the scale of the network AT ALL. People really have to get this before we can move forward with this debate.


Bigger blocks increases the amount of transactions by the same amount no matter how much extra blocksize is added. A 1:1 rate of increase. So with a maximum of about 2500 transactions in 1MB, 2MB gives 5000 per block, 4 MB gives 10,000 per block etc etc.

THAT'S NOT THE ENGINEERING DEFINITION OF SCALING UP. It's literally keeping the scale the same.



2nd layers are the first way to go with real scaling, because they're developed, tested and proven. They're not perfect, but they don't need to be used for everything, and they work better for the most useful case anyway.

So, Lightning is a great fit for IRL bricks and mortar shops. I'll explain -

• Lightning transactions are confirmed instantly, the confirmation concept doesn't really exist in LN, because the transactions don't go into a block, so there is no block to wait for for confirms
• The shops can run their own Lightning node to use with their customers, instead of giving fees to banks or Card Companies like they do now
• Lightning's main flaw is that people who you deal with on the LN can try to screw with you by doing replay attacks and such. IRL shops need their customers to trust them, and are strongly motivated not to do that
• This avoids the "Hub" situation often misleadingly depicted as the problem with Lightning. You don't have to use a big channel that's acting as a Hub, you can use small channels that independent small shops can open for themselves

Because Lightning can fit 1000's of times the amount of transactions more into a block than on-chain bigger blocks can (because it's >1000:1 scaling, not 1:1), it's actually going to give us a more efficient network. It doesn't work well the more you have to trust the other party, but like I say, it works well for some cases and not for others.


For on-chain scaling, we could reduce the target of the time between blocks, currently targeting a 10 minute average. I don't know how much we could reduce it by, no-one has ever done testing of this on a Bitcoin testnet that I'm aware of.

BUT, the problems this could create (more orphaned blocks, so less confidence in the number of confirms that are considered safe) have been vastly improved because of all the improvements made to the efficiency that blocks are now relayed across the network (the dedicated Block Relay network and the Compact Blocks scheme have done the most to enable this possibility). These relay latency improvements will have given the developers SOME extra room in the propagation behaviour to reduce the time between blocks. Maybe it could be reduced to 5 mniutes, and that would have the same effect as a 2MB blocksize (i.e. half the interval, double the tx rate). This would mean changing the 25BTC block reward for mining by half too, otherwise we'd end up with far more than 21 million BTC total, which would not be good.

---

There are many many more way than just 2nd layers (other 2nd layer sclaing proposals are beginning to appear), or block interval reduction that could ACTUALLY change the scale we use the resources of the network.

But, and I reiterate, BIGGER BLOCKS DOES NOT IMPROVE THE SCALE. It creates more transactions per second, but LEAVES THE SCALE OF THE NETWORK THE SAME. For that reason, it's a dangerous last resort, definitely not what we should be considering to do FIRST.

Usual lying by omission from you jonald


Gavin did these tests on his domestic 20 Mb/s connection. That's nowhere near what a typical internet user can even get access to, let alone afford.



Satoshi put in the 1MB, long before Bitcoin rebranded to Bitcoin Core



Bigger blocks are NOT the best way to increase the transaction rate


Bigger blocks are the most dangerous way to increase the transaction rate, there are OTHER OPTIONS APART FROM BIGGER BLOCKS. We should do the least sensible, most dangerous increases LAST, not FIRST.

If those people (i.e. people with 1Mb/s internet) are totally unimportant, why did they form the central component of your previous argument

But your example is not analogous to a peer-2-peer system, so it's not meaningful. You may as well be one of these people that say "why can't the miners mine BTC faster to solve this"

There are probably more people with 56 Kk/s connections than any other speed (and less, even more people have access to only 28 kB/s)

Your idea is to force people with 56 kB/s to use their ENTIRE INTERNET BANDWIDTH to download 32 MB blocks? Which get solved ON AVERAGE every 10 minutes, and in reality can (and often do) occur 2-3 seconds apart because of the variance around that average? 28 kBs be damned. Great plan



Right, and none of those financial companies would dream of jeopardising their very valuable trading systems by pushing the network resources used right up to the limit, they would employ a provable margin of safety, and find a better way to improve their transaction rate. This is not difficult to understand

The 2nd strawman argument that you've made against me.


My argument is that diplomatic tension is rising between the states that adjoin the South China Sea. One of those states (Phillipines) has switched allegiances from one major military superpower (US) to another (China) just recently. The president of The Phillipines has denounced international organisations strongly (threatening to burn the UN assembly building to the ground, for instance), and is being investigated by the International Criminal Court for crimes against humanity.

Separately, the US, China and Japan are all having a stand off between one another over disputed islands right in the middle of the exact same region.

And if that wasn't enough, one highly unpredictable, volatile nuclear armed state (North Korea) is exhibiting increasingly bellicose rhetoric towards ALL parties.

If that doesn't sound like a plausible tinderbox ready to catch fire, I don't know what sort of scenario you would actually consider potentially dangerous. It's a serious threat, and it's only 1 out of many possible serious threats. It's likely there are even threats to the internet's operation that no-one could have imagined, hence my focus on margins of safety and risk analysis.


Now, how is any of that either implausible or a circular argument




If you're actually interested in responsible scaling, maybe you could investigate them too? But I doubt that you are, you've spent far too long defending your entrenched and dogmatic position, when you don't really have any good arguments to support it.



Which part of "explore the possibility" do you not understand?

The orphan rate has been improved vastly now we're at version 0.13 - 0.14. The amount of slack that frees up COULD be used to safely reduce the block interval, but that would have to be proven on a test network before any proposal could even be made.


And maybe you have something to remember; Segwit itself is a blocksize increase, of 4x. A 4x increase is NOT to be underestimated in impact, increasing resource use by a factor of 4 is very large for a peer 2 peer network.

No, you didn't succeed in that at all, you demonstrated the precise opposite.


Downloading 16 TB to get on the Bitcoin network is a vast centralisation risk, as hardly anyone would do it