Didn't you get the memo, we are all going to live off of perfectly stable wind/solar power and unicorn farts for now on.

The energy sector still has a way to go down, but it will be time to reload energy stocks in a bit (after a round of bankruptcies and defaults). The current supply/demand imbalance will not knock out US energy which has more than enough of a capital base to ride this out, but will severely damage supply from dystopian basket cases such as Venezuela (the country of my birth) and Iran.

That's a good way to put it. He keeps putting up detailed scenarios, and then always asks "isn't this right" or "what is wrong with this" or "please read x, y, z and tell me what is wrong". Then someone does so, and he ignores the replies and comes back with a different scenario and repeats. Going onto internet forums and trolling for peer review is a pretty pathetic manner for one to perform research.

This. I've come across several analyses over the years the compare the amount paid into the system to the amount taken out of the system by various generations (in real terms). The silent generation received something like 400% more economic value than they paid in, of course it's a great system! The boomers are getting more than their fair share.

However over the long run, economic value in can only equal economic value out. The silent generation and boomers are getting more than their fair share by creating debt to be paid by the next generations. This is not bond style debt, but debt in the form of unfunded liabilities. However now that the worker to taker ratio is around 2:1 this debt expansion will stall, generation X is guaranteed to receive less than it's fair share.

And the millennials? Those who overwhelmingly support the EU socialist model? They are in effect debt slaves and don't even realize it since it's not debt that shows up in their household balance sheet.

You are making a valiant effort smooth, but it is not one you are going to win with this one. He make the same argument with me, in that a mining cartel could "block" all transactions they want. He refused to acknowledge that a non-conforming cartel would simply be removed from the pool, and the network would continue with the remain honest miners. He refuses to understand that the network will continue as long as there are some remaining honest miners to generate blocks.

I refuse to believe that he can not understand this, and instead believe he is simply trying out and testing new FUD against bitcoin here. Some FUD is easily refuted, other FUD requires more discussion and understanding. He has already said that he is working with his government on educating the public on the scam that is bitcoin.

Love the passion there, will have to follow his blog. Overall his thesis is accurate IMHO, the majority prefers the safety of a stable and top down static system, even if that system robs them blind of their labor and liberty. This has been true across cultures and time. Exceptional societies were the few that rejected this and relied on self reliance and responsibility of the individual. I've read about them, but have never seen one in my lifetime. This is the real hurdle to bitcoin's adoption, luckily we have human greed of a handful working in our favor...

I'd like to bump this as I am very interested in this functionality as well. It would also simplify Armory quite a bit and enable development to focus more on features.

Ideally Armory should only need to run as an SPV client. Users could then select the privacy they require by either running a local instance of bitcoind for Armory to connect to, a remote instance of bitcoind, or have Armory connect directly to the P2P network.

Running a bitcoind locally is become less and less of an option as the network grows. Some of us are stuck behind slow ISPs (my upload is 256kbps...) and SPV wallets are going to become required for many users. In my situation, bitcoind slows down my home network connection to the point that I prefer running an instance in AWS and ideally should just be able to connect to that. Gavin is also close to raising the block limit to 20MB.

I remember there was some talk from the Armory development team indicating this direction, but have not heard or seen anything in a while. It would be helpful to understand the direction Armory expects to take, since that would help with wallet planning. Thanks

I think this recent engagement with Jorge provides a window into just how hard the next stage of bitcoin adoption will be.

Many of us leap into Bitcoin once we understood it, because we were already politically aligned to it's ideology and saw a chance for Bitcoin to realize what we had already been looking for.

However this is a very small pool of people compared to the population at large. The next pools of people are those who are indifferent and those who are outright hostile/opposed to what Bitcoin represents, with the majority most likely being hostile.

Jorge is good example, he is a CS professor being paid by the state to spread misinformation. If you were already politically aligned to believe in government control of money (so they can "adjust" the supply "grow with the economy"), you are already motivated to be against Bitcoin and would accept Jorge's line of reasoning without question because it agrees with your world view. Expect more and more of his type of "analysis" to appear in credible sources.

To overcome this very real adoption hurdle I think Bitcoin can only win by becoming more and more functional and needs the ability for market participants to create and explore new functionality.

This is why I believe the sidechains are interesting and should be pursued (the concept not necessarily the current implementation).

I went quiet during the last round of sidechain discussions since it's hard to properly discuss it in thread format, but I've come to believe that economic interests by participants is what will enforce proper behavior and make the concept work. A lot of the concern seems to be poking holes in what is possible technically with sidechains, but I think economic interests would win. BTW, I believe the same is true for Bitcoin, it is economic interests that make Bitcoin work, not technical. I'll try to expand on that later.

That said I've come to completely agree with Adrian and cypherdoc that sidechains will ruin the incentivization system of Bitcoin, which is mandatory for it to function as an independent and decentralized system. If sidechains are implemented as is, I would seriously question the viability of Bitcoin to survive after block rewards become dependent on fees.

However I think there are straightforward solutions to this, largely by structuring them as childchains and not sidechains. Children chains should be forced to merge mine with their parent chain, in effect contributing all of their hash power to the parent and making the parent have the sum hash power of all children, whereas the a parent chain can mine on it's own and does not have to merge mine with anyone else. I'll try to describe this in more detail later when I have time, and then you guys can tell me where it's all wrong

TL;DR I think the concept of sidechains is needed for the next stages of adoption, but is unworkable in it's current form. So we need to find and propose the right form of a sidechain concept.

This is quite simply an insane position to take. You've created an imaginary world that does not exist in the real world and used that to extrapolate and predict behaviors that are completely opposite to how people and the ecosystem have behaved in the past, which is the predictor on how they will behave in the future.

What you describe is not even a +51% attack, it is a demand for a forced hard fork from one miner telling millions of other people what software to upgrade to. That is simply the most absurd thing I've ever heard. And the reason you think this will happen is because if that one miner claims "this change is actually necessary and good for bitcoin because the network is in grave danger", that would be accepted by the general public?

What would happen in your example is the millions of bitcoin participants would tell that one miner to take a hike and continue with the existing P2P core protocol. Then when that miner started to produce nonconforming 25BTC blocks, they would simply be rejected out of the P2P network as invalid, and the honest network would carry on. The attacking miner could have 95% of hash power and it wouldn't matter, his blocks would be rejected as nonconforming and the network would simply re-adjust to the 5% remaining. You do not even understand the basics of how a potential 51% attack is limited in it's range of attack vectors in the real world and how those limited attack vectors are harmless/manageable.

You then claim miners and users who do not upgrade would have their transactions blocked. Again this is insane. What would happen is those miners and users would confirm transactions on their own honest chain (the original chain) and not care whether their transactions confirm on the attacker's invalid chain.

Obviously, and so we are back to what I already stated, which apparently you didn't bother to read.


Which is the only possible path. This path both requires at least 51% of total hashing power, and it requires that the honest network (users, P2P nodes & miners) to ignore the 2nd chain with all transactions included. Neither of these are likely IMHO, and why the attack fails.

Bitcoin is an ecosystem of human participants, not an autonomous machine that we have no influence over. Example during the March 2013 fork the autonomous machine decided to take the 0.8 branch, but a majority of human participants decided the 0.7 branch was a better path and shifted the machine back to that (causing a 30+ block re-org btw).

If a 51% attack ever happened it would be very visible and resisted by the majority of human participants, who all want bitcoin to succeed, and who would manually choose the shorter chain made by honest miners as the valid path. Gavin's proposal would automate this selection. A 51% attack, which is what you are relying all your arguments on, is both extremely unlikely, but also ineffective. Bitcoin would easily survive a +51% attack, but it will never have to because it is not going to happen.


But thank you for reminding my why I bailed on the academic path years ago and decided to live in the real world. You, like most academics I've encountered, seem to believe that writing long-winded obtuse arguments in a vacuum consisting of your own reality, somehow makes you intelligent or valuable.

You are not, you are like a colossi striding over a very small ant-hill.

A miner does not reject blocks, a miner can only build on top of a chain of blocks.

What you are describing is an attacking miner only building on top of their blocks and not on top of any blocks. That is the very definition of a 51% miner attack. The reason an attacking miner needs 51% is so their chain, that only includes their blocks with their inclusion rules, grows faster than the rest of the network.

There are two possible paths here.
1) There are two competing chains where one chain has only the attacker's blocks and the other chain has the honest miner's blocks. The goal of the attacker is to make their chain with their inclusion rules the longest. The network here can optionally choose the honest chain (which is what Gavin's proposal does). It also require 51% to pull off, which I don't think is possible anyway.
2) The blocks from both the attacker and honest miners build on top of each other in a single chain. In this this situation the honest miners include all transactions skipped by the attacker, and the attack fails.

Gavin had a decent description of it (and other solutions) to address the possibility of 51% attack that withheld transactions a couple years ago, but I couldn't quickly find it.

It's definitely not a POS system though, mining still relies on hashing that anyone can participate in. It would only provide an additional priority advantage to blocks with more transactions in them. If all miners include all transactions in the P2P memory pool then its the same as what we have today. If an attacker decided to withhold transactions, then they'd be at a disadvantage and need progressively more than 51% of total hashing power as they processes less and less transactions.

POS provides rewards proportional to the amount of currency already owned/controlled. The scheme above is not influenced by the amount of currency owned/controlled, so it's definitely not POS.

That is the crux of your argument and it is so simply not true on many levels.

It is the P2P node network which validates and protects the integrity of the network, not miners. The miners only determine _ordering_ of transactions on the blockchain. That is how the system works.

A mining cartel can not change the terms of service, even if they have 51% or 90% of hash power. If they change the terms of service the blocks they produce would be considered invalid and rejected by the P2P network. Maybe network confirmation times would run a little slower until the next difficulty adjustment, but that would be the only impact.

About the only thing a mining cartel could do is refuse to _confirm_ certain transactions (such as black listed addresses). But unless the cartel has 100% of has power, which is impossible, these transactions would simply wait for an honest miner's block. And even this has simple solutions which Gavin and others have proposed and have ready if needed (such as including the economic value of a block's transactions in addition to difficulty, this would lower the height/priority of chains that do not include all the transactions that honest miners are including).

On top of this the miner centralization issue is not a long term problem anyway. The system will naturally decentralize over time. With the introduction of ASICS it was difficult to obtain hardware and professional setups had an advantage in procurement only. However centralized mining installations in datacenters naturally are at a cost disadvantage vs. home style setups which have free space and cooling. As the ASIC market matures I think we'll seem a shift back towards more decentralized mining anyway. Computing used to be the same way, at first we only had large centralized mainframes, today your average US home probably has 30+ processors in their house without even realizing it.

The only part that will remain centralized are pools, here the market tends to settle on 2-5 main pools historically. But pools are not a threat in regards to centralization, if any decided to cause issues the vast majority of their users would simply switch to a different pool. Attacks by pools are only effective at destroying the business model of the pool itself.

Marc made 26 great tweets today defending both Bitcoin and BTC. He clearly does not believe that Bitcoin's value is the blockchain and not BTC, which is impossible since the two are inseparable.

https://www.coinprices.io/articles/marc-andreessen-defends-bitcoin-on-twitter-in-latest-tweetstorm

+3

Those are both really cool projects, thanks for sharing. If anything their existence shows that generating true randomness on deterministic computers is hard and it is necessary to resort to the variability that is found in the real physical world.

Is there a way to provide your own self generated seed to Trezor, or do you have to use their code when plugged in? At least the code itself is auditable, but it's not clear to me if the code generates the HD seed itself, of if the code merely provides some amount of randomness which the hardware then uses to create a seed in an unknown and thus not auditable manner.

I am by no means an expert on this topic, most of what I learned came from a discussion in the Armory section which resulting in Armory changing/improving it's sources of entropy. (It's original method was probably good enough, but they were trying to further strengthen it) So the following is mostly from what I took away from following that discussion.

Even if a VM configuration is fully known and static, there can be enough entropy generated during boot time but it needs to be carefully captured and a programmer needs to know the right calls to do this. These sources can include: the current time/date, the MAC address generated by VMWare or kvm (which is not fully random), the I/O performance of the underlying storage system which can effect various orderings to the boot sequence, the times of service start initiations and completions, etc.

In a limited environment where bitcoind automatically starts as a service on boot in a known VM configuration and creates a new wallet.dat file before a user even tries to login, it is necessary to capture every possible source of entropy.

The only reason I brought this up is even though RFC6979 looks to be a great solution for safe generation of k values, wallet software still needs to correctly generate crytographically random numbers for wallet generation, which is arguably even more important.

Yes you have that correct. It is k that needs to be protected because once you know the k value used in a signature you can calculate the private key from the signature and public key.

The issue with using the same R value (which is derived from the same k value) in two different signatures is that it then becomes possible to calculate the k value used using both signatures, and once you have the k value you can calculate the private key.

Do read this link if you are interested in the topic. It explains all of the math required to understand ECDSA and DSA, but in an understandable manner and also covers the question above well.

http://kakaroto.homelinux.net/2012/01/how-the-ecdsa-algorithm-works/

Edit: looks like Peter beat me in replying by ~1min. The reason why the RFC6979 approach works is because you are guaranteed to use a different k value for each different message (due to hashing the key & message). The only time RFC6979 would repeat a k value is if the message was exactly the same, in which case you are not producing two separate signature but just repeating the same one done before.

Exactly, to make this method secure you'd have to randomly select 75.29379857239479209348238048023740720340% of the way to 2^256, which is the same as just banging out 256 bits of entropy on your keyboard (which may not even be that random depending on how you type, dice would be much better)


The issue with HD wallet seed key generation is even though it happens once, EVERYTHING rests on having true entropy during it's generation, especially for a wallet that may live for decades (which many HD wallets will). However at the same time generating HD seeds or private keys can be done when a machine and wallet software first start when there is the LEAST amount of entropy in a given machine.

For example lets assume someone decides to use a Ubuntu 14.4 VM image pre-configured to run bitcoind automatically. That person starts the VM, logs into a ssh shell, and then issues a bitcoind command to create a new wallet. This a logical user flow, but it also means the system has very little entropy. In this case everything about the system configuration is known ahead of time (it is a pre-configured VM image with known virtual hardware) and the user inputted a minimal amount of new information to capture (even the bitcoind command is known and can be easily guessed). About the only random information the user adds is their personal id/pw, but those might be quite weak because the user figures they are running on a secure home network. In this situation that machine has very little true entropy to use in private key or HD wallet generation. At the same time that key might have a lifetime of decades, during which an attacker can try combinations.

That is why it is important that the random number generator captures as much entropy from as many sources as possible. However most rnd functions do not do so by default and the cryptographically secure methods can vary from OS, i.e. a developer has to find the right function calls for linux, windows, etc.

This is why some people roll dice to generate the seed key for their core wallets, since it is the only way to be absolutely sure. I am positive that right now there probably are several individuals trying combinations on known (to them) weak setups trying to guess HD seeds or private keys.

Was not aware of RFC6979, thank you for sharing. Has any wallet software started to move in this direction or implemented this approach?

It seems this will work well for an existing HD wallet, where no new private keys need to be generated. However most wallet software needs to be able to create new wallets and still require the ability to generate cryptographically random numbers in order to create new private keys or a new HD seed. So the problem of wallet software requiring true random numbers still exists.

It could even be argued that RFC6979 might make wallet developers less aware on how to obtain true random numbers since RFC6979 "fixed" the problem, and as a result generate weak HD seeds. I remember for Armory there was a discussion last summer that resulted in more entropy being added to HD seed generation, I am sure most wallet software is not as paranoid and could still be weak here even with RFC6979. Weak HD seed generation is much more of an issue than moderately weak k value generation IMHO.

BTW, Not sure if the need for RFC6979 in general is more of a statement on how hard it is to produce true random numbers, or if this is more of a statement on the state of software engineering today.