Well, it has some loose ends... This happens if you received a transaction server doesn't know about. We need to handle this error without blowing it up.

However, I see that transaction 902a7fb4b56e291b194a1aa5ef87190e1d658a84a4f787edbe7325bf17889719 is being requested, and I can't find it anywhere. Might be transaction malleability issue, I dunno.


Well, you can delete coin_data entries in wallet, but it's probably easier to wait for a fix.

Well, the plan was to use Electrum servers and borrow code from Electrum, but that code isn't directly usable, so I used a simpler option (trust what bc.i reports) for now.

Having this in library would, indeed, help...

Well, in terms of complexity, OP_CHECK_COLOR is something I could probably hack together over weekend... Simple solution are more likely to win. (See: worse is better.)

Implementation consists of regular bitcoin SPV for UTXOs and backward-scan based coloring.


CHECK_COLOR opcode is a simpler softfork solution.

ChromaWallet 0.0.5 preview available:

Linux 64-bit: http://killerstorm.xen.prgmr.com/alex/chromawallet-linux-x86_64-0.0.5.tbz
Windows (32-bit): http://killerstorm.xen.prgmr.com/alex/chromawallet-win32-0.0.5.zip

New features:

• epobc coloring scheme solves many problem obc had
• works as thin wallet

In default configuration it doesn't rely on a local bitcoind, instead it gets data from blockchain.inf and/or chromanode service. (Electrum connector is in development.)

By default it works on mainnet, add --testnet parameter to run it in testnet mode. E.g. "chromawallet --testnet" or "cw-cli --testnet <command>".

If you want use old wallet, you can so so via "--wallet=<path-to-wallet>", e.g. "./chromawallet --wallet=wallet.db".

Note: It isn't safe enough for mainnet, don't use it with non-negligible amounts!

COGNITIVE Litecoin exchange pass-through haven't received dividends since 2013-12-22:

https://litecoininvest.com/security/COGNITIVE-PT/history

It is profitable to run it. BUT it is more profitable to sell it than to mine with it.

It was even mentioned why: there are people who want to buy mining hardware and do not care about doing "real analysis".

One can simply record this information and wait until he gets complaints.

Normally there is no need to do anything. When a complaint is received, knowing inputs he can check whether these inputs are spent, and thus determine if complaint is valid or not. (If it is a valid complaint things become tricky, at that point consultation with specialists might be necessary as bitcoind won't just forget about wallet transactions.)

If you want an automatic sanity checker, the easiest way is to lookup spends of these coins via some kind of a block explorer API, in this case it might be just like a dozen lines of code. If you don't trust external block explorer, run your own ABE instance.

Processing block data like DeathAndTaxes described is also an option, but requires more code

Making custom Bitcoin clients, in general, isn't easy. It should be avoided unless it is absolutely necessary.

If you're asking a question like this, then you're simply not qualified to do this.

ITT: People who have only a very vague idea about how Bitcoin works offer solutions and propose protocol changes.

Seriously, if you haven't read the source code, SHUT THE FUCK UP. You're simply not competent to say anything on this matter.

This mess was caused by people who weren't competent enough, do not make it worse by making strange noises.

(What you wrote above is ridiculous, you have no idea what is "TX ID" and how it is used, how it is included into blockchain etc.)

It makes sense to find all transactions which spend same coins.

1. No such transaction -> txn was not included into a block
2. One such transaction -> that's what we're looking for, now check its outputs
3. More than one transaction -> bug in software, investigate

Unlike what you described, this check can be done with simple tools like block explorer (or, automatically).

E.g. suppose software says that transaction in question spends b8bdf71e9e3ee414fa57144cd971fa665fe07aacf1b9203cac485859000d3895:1

Then you look it up: https://blockchain.info/tx/b8bdf71e9e3ee414fa57144cd971fa665fe07aacf1b9203cac485859000d3895/1

Red link (Spent) points to a transaction which spends this output, which is the transaction we are looking for.

(I simply want to clarify that it is better to look up inputs one by one than look up "the unique set of inputs" (whatever it means)).

You're wrong, it doesn't need to be fixed. It is gox's problem.

If you have problems understanding how it works, read this: http://www.reddit.com/r/Bitcoin/comments/1xiowj/explain_the_gox_transaction_malleability_issue/

What we take from it is that it is a bad idea to rely on closed-source wallets, as it is likely that dude implementing it will miss something.

The goal isn't to "spot modifications", the goal is to check if transaction was included into a block.

Generally speaking, attacker can only modify scriptSig(s), so if you compute hash of a transaction without scriptSig(s) (like how it is done for signing purposed), that hash will be unique: if you spot transaction with that hash in blockchain then transaction was successful.
.

Yes, but what I described above can be a drop-in replacement in a gox-like system: simply use a different hash as a txid.

But, yeah, whatever...

The trivial fix it to use the hash which is used for signing as a transaction identifier. Should be fine for all standard transactions.

You're wrong.

Within a simple model where difficulty is proportional to Bitcoin price in US dollars (or, maybe, just correlates with it positively), investment in mining securities is essentially a bet against rising Bitcoin price.

In reality it is much more complex, but the general idea is the same. You can dig up a story of burnside's Litecoin mining bond, it provides empiric evidence to this theory. (Rapid rise of Litecoin price -> rapid decline of perpetual bond value.)

If you have a crystal ball and are 100% sure that Bitcoin price will go up, it probably makes sense to keep bitcoins in your paper wallet.

But ordinary people do not have a crystal ball, and they know that Bitcoin price can go down, or stagnate for a couple of years. That's what happened July 2011 - January 2013, after all.

So they need to hedge... Obviously, one can just sell his bitcoins and keep US dollars, we can consider it a baseline.

Buying mining-related securities is another way to hedge it.

And thus this graph definitely makes sense:

1. it shows performance of investment into mining security against default hedge strategy (keeping US dollars)
2. in general, price of mining hardware is in USD, so in makes more sense to price mining company shares in USD as well... they are traded on Bitcoin exchanges, yes, but Bitcoin can be seen as a payment system here.

tl; dr: You'll see how it works if you won't look at it from permabull's position.

Reminds me how pirateat40 tried to paint it as a logistics issue (moving coins between accounts is so hard!), not insolvency issue:


This is hilarious:


There was kakobrekla analog back then too:

As you see, I failed to complete it in January as promised. It happened not because the task is big, but because we made very little progress, sadly things didn't go well.

However, it looks like things are getting better now and we'll be able to make good progress. The deadline is two weeks (Feb 14), but I hope I'll get something sooner than that.

A lot depends on me personally at this stage, so if I'll get ill or something we'll get more delays

No.

What are you talking about? As far as I know, Counterparty is NOT about "trade between muliple block chains". And neither is Freimarkets.

You need something like this:

https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains

But it depends on non-standard scripts, so won't work so well right now.

Well, basically one creates 10^15 atoms, 10^6 atoms represent 1 share. (That's simply a display convention, for convenience.)

OBC represents 1 atom with 1 satoshi. But ITOG does not.


M. Sc. in applied math.