It's good to know there is a plan out there to have ultra pruned tree verification. The hashes you mentioned are going to incorporated in Merkle trees? I thought that the Bloom filter mechanism was going to be extended to skip over used tx.

In any case, would it be compatible with deterministic wallets? Without the used txs, they will stop scanning for addresses too early.

Who is hosting the AT?

You guys say that hard drives are cheap but you still have to scan the block chain at first. It takes a very long time to do but is the only trust less solution, isn't it?

As a merchant, the only way I see things going is to keep the block chain whatever its size becomes, and sync.

It would be good if there was a way to drop the used transactions from the requirement. Last time I checked, there was 27 gb of block data but less than 1 gb worth of active tx.

It's an old video card and there are a few improvements that I can see. It's a baseline.
L

I made an openCL version of sipa's secp256k1 library. It's on github if someone is interested. It executes faster but only after you throw hundred of thousands of signatures to verify.
On a sample test run
# of sigs = 262144

Times in ms per phase.

prepare -> 2518
compute -> 15201
check   -> 35
total   -> 17755
           0.067733

Phase 1 & 3 are on CPU. Phase 2 is on GPU. 0.067733 ms per verification.
I have a GTX 560 Ti.

Do you have recommendations?

My current thinking is that the best bang for the buck is parallalizing the two group multiplications (by G and Q).
They use the field doubling and multiplication that were optimized in asm and they must be put on the device.
The rest that uses GMP isn't very much. It's a modular inverse and a few mult/add. It barely registers on my execution profile.

Thanks

Let me rephrase.
If a miner refuses to include a non standard tx, it's not too bad. The transaction will not confirm and the money stays in the original address.
With a pay 2 hash script, the miner can't tell if the transaction is standard or not and will include it. Now the money is transferred. If they refuse to accept a non standard redeem script, it will be stuck there.

May be it is an acceptable behavior but I understand that they mine non standard tx in this case.

Wouldn't you be unhappy if it is ok to send money to these address but impossible to spend because the script is non standard?

They are pay 2 script hash. One can't tell is they are standard before they are redeemed.

While I think that for the most part a country wide network split is unlikely to go undetected, I see two possible scenarios:
- A long lasting split. In this case, the smaller side has ample signs that it has become the orphan branch. Further transactions should be carried out considering the risk that they will become unconfirmed when the merge occurs.
- A movie scenario, where a hacker isolates a significant entity without them being aware of the situation in time for him to do his double spend.

Both are far fetched. Back to the original topic, the OP doesn't have to worry about the loss of the blockchain as it is already kept redundantly by thousand of nodes. If these all go away, it would be because Bitcoin has ceased to exist.
 

That's a good point. It's statistical though and using it as a programmatical way to determine a split would be wrong.
I suppose we need to frame the context of this scenario. There is a network split and no human decision can be taken while this happens. Highly improbable but otherwise we couldn't have such a split happening in the first place. Maybe a more probable scenario is if there is a bug that introduces a different behavior for half of the nodes.

Yes - but they are not allowed to communicate.

Right. I forgot that orphaned transactions simply return to the mem pool.

It could be possible for a mischievous person whereas the common person is unprepared especially if this is the result of a deliberate attack.

Hard to say. There are human factors to consider too.

You would need to cherry pick the double spends.

From a definition point of view, the longest chain is the good one. But this is still unpleasant to the victims of the double spends.

The system actually does it automatically by rerolling orphaned transactions. The manual part would be the result of customer complaints. People who are not happy with the result will call their merchants.


I hope not, because this would be a waste of time.

Note that Satoshi already answered most of this back in July 2010:


I don't see why it is so hard to do a double spend though. You don't have to be connected to both network. You need to know people who are and then ask them to broadcast the transaction for you.

Decentralized systems are very sensitive to network splits even for short duration of time. Let's say the Internet is split into two zones for a day. Users and miners in each region will continue to work without being aware of being isolated from each other. We would have two versions of the blockchain - which for all matter and purposes - are both valid.
It is called a split brain. http://en.wikipedia.org/wiki/Split-brain_(computing)

When the Internet recovers, the blockchain with the longest difficulty will prevail, making the other one orphan. All the transactions that happened in the orphan chain will be considered invalid causing loss to the merchants that sold goods.
Not to mention that double spends can happen at will in this scenario if someone has a connection to both networks.

In conclusion, the current design of Bitcoin does not cover the scenario of an Internet split. It goes beyond the need to recover a blockchain. There would be no good blockchain and recovering would require manually stitching the blockchain together. Is this what you want to tackle?

This transaction https://blockchain.info/tx/251d9cc59d1fc23b0ec6e62aff6106f1890bf9ed4eb0b7df70319d3e555f4fd2
has a messed up DER encoding too.

3044022090f7346fa0f6a4dc4b31300bf93be229001a1104532829644e07f45814bb734e0220579da5a14362f 46bfd7c2be0d19c67caedc812147b9b8d574e34a3932cf21f7a01

It's definitively not consistent.

It wouldn't but it would break using standard crypto libraries. Bitcoin isn't consistent in this area though. Most likely the result of legacy.

There is an extra leading byte of 00 to indicate the sign. Without it, the number r or s would be treated as negative because its most significant bit is 1.

Your unconfirmed transactions have a non standard input. Did you create them manually? If so, what is the raw transaction?
It was not propagated beyond blockchain.info and is not in the mining pool.

Yes it's possible. It has been discussed as an improvement for a long while. It's not implemented.
The blockchain is 27 gb. The active part is less than 800 mb.

I am working on a thin client that would use a configurable amount of space

Elliptic curve mathematics is much more complicated than this. Besides, there are technically multiple values because the EC forms a cyclic group but we choose the normalized value. anyway Why the sarcastic comment?

It doesn't matter. When you merge back, it is the cumulative difficulty that counts for the longest chain.
Basically you are proving work, not your ability to create blocks.

1. The hash function maps billions of 256 bits input to the same value.  It's just that it's not computably easy to find a collision.
2. Bitcoin verifies that you can spend from an output by checking that the public key that you provide has the same hash the address and that you have the private key.
In other words, when the money was sent out, only the hash was given. To claim the money, you show the public key.