If RSK is open source wouldn't it be possible to fork the code and remove this "tax" on mining? 

That is a very weak connection. There are a lot of things written in Java. Such as Android phone and apps. 

Hello guys,

I have been interested in currency trading since 2011 and I have pretty much learned the basics (even more probably) of the day trading, technical and fundamental analysis. I understand the concept of the Bitcoin and its trading in general.

I'm curious as to why ETH should fetch a large value. Bitcoin has value because it is explicitly a store of value, as well as a payment system. Transfer fees are pretty much insignificant (cents). Ethereum's value only comes from it's ability to run decentralized Turing-complete code. Since you're paying per execution, most people will actually want the value of ETH to be low as possible, so they can execute their programs as cheaply as possible. This will lead to people rapidly dumping when they feel the price is too high, and sitting on the sidelines to wait until prices are reasonable and then buy in and quickly run their scripts at a cheaper price. Or, more likely, most people won't hold ETH at all, and only buy in a small amount at market price to cover the cost of whatever script they need to run. Large initial inflation combined with no software running on the network in the beginning will mean ETH effectively won't have any intrinsic value until the first programs are released. Any rises in value after the IPO and before the release of programs will be purely speculative.

The coefficients will be revised as more hard data on the relative computational cost of each operation becomes available. The hardest part will be setting the value of x. There are currently two main solutions that we are considering:

Make x inversely proportional to the square root of the difficulty, so x = floor(10^21 / floor(difficulty ^ 0.5)). This automatically adjusts fees down as the value of ether goes up, and adjusts fees down as computers get more powerful due to Moore's Law.
Use proof of stake voting to determine the fees. In theory, stakeholders do not benefit directly from fees going up or down, so their incentives would be to make the decision that would maximize the value of the network.
A hybrid solution is also possible, using proof of stake voting, but with the inverse square root mechanism as an initial policy.

Good stuff.

The reference Bitcoin implementation obfuscates the core simplicity of transaction validation by oddly referring to scripts as "scriptPubKey" and "scriptSig" instead of "inputScript" and "outputScript".

Realizing that "owning bitcoin" just means that you can provide a stack of instructions that evaluates to true when appended to another arbitrary instruction stack is what inspired me to hack on Bitcoin in the first place.

Some feedback:

• It's worth pointing out that "true" is really just "any non-zero value" rather than a boolean literal. In other words, a script is logically valid as long as the top stack value is not 0 and as long as the evaluation isn't short-circuited by an instruction like OP_RETURN.
• The significance of instructions like OP_RETURN and OP_VERIFY is that they short-circuit the evaluation. Otherwise, the script will evaluate in full and the final top stack value will determine the state of the stack. That's why you can append arbitrary data after OP_RETURN -- it's so that the data won't be evaluated.

I like. I mirrored it at my website: http://www.bitcoinhistory.net/ under "Technical Papers".

Yes, but if you point to a Testnet obelisk server in your sx.cfg file, it should fix that. The list of servers is at https://wiki.unsystem.net/index.php/Obelisk/Servers. There is one Testnet server listed and it appears to not be working for me.

One bit of feedback.  It wasn't immediately obvious to me that OP_EQUALVERIFY would cause PubKeyHash and PubKeyHash2 to be removed from the stack.  You stated:


So I thought this meant that OP_EQUAL would simply add TRUE to the stack when they are equal, and that OP_VERIFY would remove the top element ( TRUE ).  But this would leave PubKeyHash and PubKeyHash2 still in place.

So I reason that OP_EQUAL must also remove both input elements, and probably most operators do that when they evaluate to TRUE.  But I'm not sure that you explicitly state that anywhere.

So logically if we used OP_EQUAL and then OP_VERIFY we would have:

TRUE
PubKey
Signature

after OP_EQUAL and then

PubKey
Signature

after OP_VERIFY.

yes?

I really like your introduction.  It is essential that somebody produces some tutorials on general transaction writing.

Thank you!

Ok, what's up with the flood of noobs posting links in here?

If you have something to say, say it here.