Are there any sidechain ideas or proposals that depend on the ability to create non-malleable transactions?

If so, why?

I would like to better understand the problem of fraud proofs and false flagging fraud hints with normal SPV (headers only+merkle branch).

I understand the two difficult cases:

* A transaction included that references a non-existing output. Absence of the referenced tx cannot be proven.
* A TXID included of a non-existent transaction, and a transaction is included that references it. This also cannot be proven.

Now both these cases can only be *hinted*, and it is said that to verify such (cheaply faked) hints, the SPV falls back to full node.

But what if the SPV simply registers the hint for a transaction in block N, and uses this hint to ensure every received transaction in block >= N must request all ancestors up to block N-1 for verification?

Requesting ancestors seems no bad practice, so this makes both false flagging attacks as well as attacks using invalid blocks unfeasible, and protected by normal anti-DoS measures.

What am I missing here? Why does the SPV need to fall back to full node?

I would like to understand the advantages of the script versioning introduced in SegWit.

As I understand, script versioning allows you to change the meaning of existing opcodes, where currently we can only add opcodes.

Why is this needed? Isn't the power of this simple stack based language that you can add *any* functionality simply by adding new opcodes, (and can do so indefinitely with an OP_EXT), without the need for versioning?

Isn't that a very clean mechanism to update this language while retaining backwards compatibility? Especially because due to the immutability you can never deprecate old functionality.

I have showed earlier how Bitcrust uses a Spend Tree to track the transaction graph and verify order.

I believe this same structure can also be used to tackle the difficult Fraud Proof problem by making the processing of hints indicating absent transactions, virtually free.

I propose creating a "Fraud Proof SPV" node (FSPV), by syncing this Spend Tree. It is explained here: https://bitcrust.org/blog-fraud-proofs

Please let me know what you think,

Tomas van der Wansem
Bitcrust

I have build a storage engine as the core of a new Bitcoin Node in development. The idea is to abandon the UTXO index and use a fast concurrent spend tree instead.

The results are very promising. Further information is here: https://bitcrust.org

Performance results: https://bitcrust.org/results

Source code in Rust is available at https://github.com/tomasvdw/bitcrust

Hello there,

All of a sudden, electrum.exe won't start anymore. When started it briefly shows up in Task manager and is gone after a second. I don't see logs or console output.

- I don't have the twelve word seed.
- I do have a wallet.dat and blockchain_headers in APP_DATA. wallet.dat looks valid.

What procedure should I follow? Reinstall electrum and then overwrite wallet.dat with my current one? Would that work?

Does wallet.dat contain my private keys without the need for the twelve word seed?

Thanks!
Tomas

[Features]

Hello,

We have created a new soccer betting website at https://btcsoccer.com.

Mainly because I really like the idea of gaming and gambling without having to login. It really feels magical to be able to play without all the hassle and trust, just by scanning a QR code.

Features

- Betting on all major European leagues.
- Live match updates
- Direct payout after the game
- 2% house edge, only on profits

Please check it out and let me know what you think...

Tomas
https://btcsoccer.com

Hello,

I am having some trouble with creating transactions using python-bitcoinrpc (on python 2.7.x).

It seems that the library doesn't support the Decimal data type; when I do:

Code:

new_tx = btcoind.createrawtransaction([{ 'txid': mytx, 'vout': myvout}], { to_addr: Decimal('0.001') })

It raises:

Code:

...
  File "/usr/lib/python2.7/json/encoder.py", line 184, in default
    raise TypeError(repr(o) + " is not JSON serializable")
TypeError: Decimal('0.001') is not JSON serializable

I have seen some solutions (http://stackoverflow.com/questions/1960516/python-json-serialize-a-decimal-object?)
but they all seem to entail converting the decimal either to float or to string. The first is not an option due to the loss of precision and the second creates a json-rpc error.

How can I ensure the decimal is properly encoded to json?

Thanks,
Tomas