I had a similar problem, just fixed it https://bitcointalk.org/index.php?topic=1513497.0

If you are willing to send me by private message the wallet password and the main wallet file,
I can retrieve those coins for you (no wallet words required).

The price is not going to be that high at the end of 2016 I am so sure of that we have not even reached the thousands yet so it would be very unlike to be that high.
At the end of 2016 I believe that the price is going to be max $1000.

Apples and oranges.

The content of your scriptpubkey, beyond the resource costs to the network, is a private contract between the sender of the funds and the receiver of the funds. It is only the business of these parties, no one else. Ideally, it would not be subject to "consensus", in any way/shape/form-- it is a _private matter_. It is not any of your business how I spend my Bitcoins; but unfortunately, script enhancing softforks do require consensus of at least the network hashpower.

Bitcoin Script was specifically designed because how the users contract with it isn't the network's business-- though it has limitations. And, fundamentally, even with those limitations it already, at least theoretically, impossible to prevent users from contracting however they want. For example, Bitcoin has no Sudoku implementation in Script, and yet I can pay someone conditionally on them solving one (or any other arbitrary program).

Bitcoin originally had an OP_VER to enable versioned script upgrades. Unfortunately, the design of this opcode was deeply flawed-- it allowed any user of the network, at their unannounced whim, to hardfork the network between different released versions of Bitcoin.  Bitcoin's creator, removed it and in its place put in facilities for softforks. Softforks have been used many times to compatibly extend the system-- first by Bitcoin's creator, and later by the community. The segwit script versioning brings back OP_VER but with a design that isn't broken---- it makes it faster and safer to design and deploy smart contracting/script improvements (for example, a recently proposed one will reduce transaction sizes by ~30% with effectively no costs once deployed); but doesn't change the level of network consensus required to deploy softforks; only perhaps the ease of achieving the required consensus because the resulting improvements are safer.

If you're going to argue that you don't want a system where hashpower consensus allows new script rules for users to use to voluntarily contract with themselves, you should have left Bitcoin in 2010 or 2011 (though it's unclear how any blockchain cryptocurrency could _prevent_ this from happening).  Your views, if not just based on simple misunderstandings, are totally disjoint with how Bitcoin works. I don't begrudge you the freedom to want weird or even harmful things-- and I would call denying users the ability to choose whatever contract terms they want out of principle rather than considerations like resource usage both weird and harmful--, but Bitcoin isn't the place for them, and the restrictions you're asking for appear to be deeply disjoint with Bitcoin's day-one and every-day-since design, which has a huge amount of complexity in the original design for user (not consensus) determined smart contracting and where softforks (hashpower consensus) have been frequently used to extend the system.

I asked some of these questions 3 months ago.  Never got a decent answer.

Blockstream wants soft-forked SegWit to fix the malleability problems (that would be needed for the LN, if they ever get it to work), and to force ordinary p2p bitcoin users subsidize the costs of complicated multisig transactions (ditto).  But these reasons do not seem explain the urgency and energy that they are putting on the SegWit soft fork.  Maybe they have other undeclared reasons?  Perhaps they intend to stuff more data into the extension records, which they would not have to justify or explain since, being in the extension part, "ordinary users can ignore it anyway"?

As for SegWit being a soft fork, that is technically true; but a soft fork can do some quite radical changes, like imposing a negative interest (demurrage) tax, or raising the 21 million limit.  One could also raise the block size limit that way.  These tricks would all let old clients work for a while, but eventually everybody will be forced to upgrade to use coins sent by the new verson.

[bold]Script versioning[/bold]
Changes to Bitcoin’s script allow for both improved security and improved functionality. However, the design of script only allows backwards-compatible (soft-forking) changes to be implemented by replacing one of the ten extra OP_NOP opcodes with a new opcode that can conditionally fail the script, but which otherwise does nothing. This is sufficient for many changes – such as introducing a new signature method or a feature like OP_CLTV, but it is both slightly hacky (for example, OP_CLTV usually has to be accompanied by an OP_DROP) and cannot be used to enable even features as simple as joining two strings.

Segwit resolves this by including a version number for scripts, so that additional opcodes that would have required a hard-fork to be used in non-segwit transactions can instead be supported by simply increasing the script version.

Well to run a node one requires three things:
1) Processing power (for validation).
2) Storage (for storing the blockchain).
3) Bandwidth (for relaying data).

Currently the block size limit is at 1 MB. Now when you try increasing that to let's say 2 MB, you are essentially increasing the requirements listed above. One could argue that decentralization is Bitcoin's biggest pro. Now if you make the requirements too large, then a decrease in the number of nodes will occur. This is why you've heard of "Bitcoin ending up on super nodes". We can not let this happen.

---

---

So to avoid this, the plan is to be very conservative on the block size increases (only safe limits) to retain decentralization and build a second layer (e.g. Lightning Network). Such a layer enables a much better (efficient way) of scaling.

Shortly before disappearing, Satoshi also repeated over and over that there were more ways that Bitcoin could be successfully DOS attacked than he could count.

The limit (in conjunction with transaction fees) were intended as a DOS attack and spam deterrent. Do you have any evidence that those risks have been mitigated? Do you have any evidence that suggests that 2MB blocks won't be filled to capacity right away? That would leave us where we are today -- with no scaling solutions, wondering how much more un-optimized throughput the network can safely handle.  


Satoshi's description of how to increase the block size limit was also clearly in the context of a software update. Not an incompatible implementation of bitcoin that essentially attacks the network and intentionally forks from all other client nodes. He even thought compatible alternatives were a bad idea.

One could make the argument that Satoshi thought we could raise the limit as/when needed (as if we needed his authority anyway). In that respect, the question of necessity is subjective and debatable, and it is not immediately clear that an increase to 2MB now, with no attempts to make throughput more scalable is necessary.

One could not make the argument that Satoshi thought we should increase the block size limit through a contentious hard fork.

All of this is moot. We should be talking in terms of "what is best for bitcoin" -- with respect to users, nodes and miners -- not talking past each other with interpretations of things Satoshi said 5-6 years ago. Not only was Satoshi wrong about some things, but the state of bitcoin has changed a lot. Hell, if we left the codebase as he originally wrote it, those 184 billion bitcoins from the August 2010 value overflow incident would still be with us. Better to work towards bitcoin's principles than aimlessly trying to fit some arbitrary interpretation of Satoshi's words.

I've read some long discussions about the pros and cons of miner's publishing zero transaction blocks (as 'some' are doing now).

The TL;DR is that:

Let's say the blocksize was 10MB and it took 10 minutes to solve a block. Miners would work on solving it but a large zero-miner would quickly solve a zero sized block. They would them publish it to their "large miner friends" who would start solving a next block.

Whoever solved the 10MB block would likely get their block orphaned if the empty block + next block was published immediately after the block was solved/broadcast. And whoever was working on the longer chain would be already working on the next empty block + next block.

In a way, publishing empty blocks seems to create an artificial cap on blocksize, does it not? As the blocksize gets larger and it takes longer to solve blocks, publishing empty transactions can cause more and more transactions to be orphaned.

Additionally, some (many?) people support miners publishing empty blocks. There seems some back and forth whether this should be allowed at all. As it is part of the protocol, disallowing it would seem about impossible at this point in time.

Doesn't this basically put a blocksize limit in the hands of the large miners? And isn't this just a way for the largest miners to gain an advantage over the others? Or is there some reason this is a "good thing"?

You are missing my point because you are assuming that the motivations of all participants is that of monetary profit. You can't just ignore the observation that decentralized cryptocurrency represents the only real threat to the central banksters in a very long time. The point is the same for 64MB as it is for 2MB, only more obvious in that the problems 64MB would create are much greater.

That's not even really the appropriate question. The real question you should be asking is "What would prevent someone who wants to destroy the network from producing such a block?"

But you don't ask that because ... (you tell me).

This transaction monopolization can only happen IF all the other mining pools choose to mine on top of that monopolizing mining pool's blocks. Yet, doing so will result in lower profitability for the other (the majority) of pools since they (having smaller validation capacity) must always mine 1-txn blocks and are therefore unable to reap transaction fees. This is an unstable situation - if a single mining pool chooses to ignore the large block and is able to find a small competing block while other pools are still validating a large block, it is in the other pools best interest to switch to this new sibling6. By switching, the other pools reduce the risk that they are mining on top of an invalid block, and can mine blocks with transactions. But if mining pools know that the majority will switch to a discovered sibling, it is rational for all pools except for the producer of the large block to search for a sibling rather than produce a 1-txn block.

I doubt that, the DDoS can easily be defended with fail2ban[1]. It would be easier to install a very common admin and protection tool you should have anyway (even if you just use it to defend against SSH brute force attacks) than to move the entire server.


A actually distributed DoS (as in ran by multiple people and not a bought bot net) is seen as a form of political protest by some. I do agree however that hiring a bot net to attack classic is a stupid idea, whoever is behind it.

[1] https://bitcointalk.org/index.php?topic=1380642.msg14103169#msg14103169

There's nothing natural about it.

It isn't a solution. It is a workaround that prevents certain types of transactions.

I don't have time to follow that thread. So this is the worst case scenario? If we assume that this is true, then then Segwit seems pretty good. Added capacity without an increase in the amount of hashed data and no additional limitations. Did I understand this correctly?

Thank you so much sgbett; that was a really great read.  I must admit I didn't work through all of the math yet but at first blush it appears ok until;
Hmm, really?  There's no way ever to improve on block validation times?  Quantum computers?  Nothing?  That doesn't ring true.

agreed.

I don't think that there are many transactions that are so large in nature (both 'abusive' and non). This is the one that I'm aware of. However, you'd also have to define what you mean by "big". Do you mean something quite unusually big (e.g. 100kB) or something that fills up the entire block? I'd have to a lot more analysis to try and find one (depending on the type).

TX malleability (e.g.) is 'undefined'? Segwit provides additional transaction capacity while carrying other benefits. How exactly is this bad?

The question would have to be correct for one to be able to answer it. In this case, I have no idea what you are trying to ask.

It is certainly not a hacky workaround. It is a limit that was needed (it still is for the time being).

If it can be avoided, not really.

So exactly what is the plan, replace one "hacky workaround" with another? Quite a lovely way forward. Segwit is being delivered and it will ease the validation problem and increase the transaction capacity. What is the problem exactly?

Satoshi was wrong about so many things.

<snip>
Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.
</snip>

No. You don't get to define what we allow in the system and what we don't, certainly not when it was possible all this time. What Gavin proposed is a hacky workaround, nothing more