I don't use Bitcoinica, but you shouldn't have to convert first.

Don't forget: fees; you're paying the spread twice; and your 9k buy will move the market up and the ~9k sell will move it down cutting into your profit both times.

Also don't forget: if the market goes down $0.48 you will be forced to liquidate and lose 100%.

You are correct.  Apparently I should read the material I cite.

For practical purposes an offline client such as Armory or an online wallet like (pick your favorite) will work fine over any phone line.

On the other hand I'd still like to see this happen just because it's cool. 

Market: buy/sell immediately at the current market rate.  You pay the spread.
Limit: Offer to buy/sell at a price.  When someone executes a complimentary market order that's better than your offer, your order is filled.
Stop: Execute a market order when the price crosses a setpoint.
Trailing stop: A stop order that follows the price.

http://www.investopedia.com/terms/m/marketorder.asp
http://www.investopedia.com/terms/l/limitorder.asp
http://www.investopedia.com/terms/s/stoporder.asp
http://www.investopedia.com/terms/t/trailingstop.asp

Options: http://polimedia.us/bitcoin/options.php

Don't start with 10:1 leverage.  You'll lose your entire 1 KBTC faster than you earned it.

https://bitcointalk.org/index.php?topic=34163.0

It requires one extra step - cut and paste the key it generates into Armory.

Certainly someone can glue the two together if that step is worth 10BTC to you.

The point is it could have been manipulated before hashing.

For the purpose of documenting the fact that damage occurred before a certain time this technique works just fine.  The other side would have to argue that you photoshopped up some fake damage intending to do the actual damage later.

They still have to access the Bitcoin network to get the previous block so they can work on it.  I'm hoping they're getting it from the same node.  If it's being distributed through their C&C network, we lose.

The fact that it's possible to download the whole thing onto a RAM disk, manually copy it to disk, and sync with orders of magnitude less of an IO hit suggests that the DB is doing something pedagogically.

I was just kidding, but everything you say is correct.  The startup and shutdown times are very high.  SOME disk hit is expected, but it's still quite excessive.

They used to be much too close; hence the adjustment.

Obviously there's still considerable room for improvement.  

Edit: And why would you ever quit Bitcoin?  You smell like a traitor. 

Yes, I agree - the goal isn't to find the C&C (modern botnets are using decentralized C&C anyway), just to get a list of drones.  I personally think it's not worthwhile to hunt them down one at a time, but other people may be inclined.

Database transactions require writing a journal, syncing, writing the data, syncing again, and then deleting the journal.  That's a much harder disk hit than linear writes.

Try using the just-released 0.6.0.  The settings have been changed for better disk performance.

Read more carefully:




I agree that it's a longshot for the ISP to pass a message to their customer, but if Mystery keeps using new relays we may eventually get one that will work with us.

Of course, the end result is we just get a long list of IPs.  Tracking those down and notifying them is an uphill battle, and not worth my time, but if other people are up to it I'm happy to help get them a hit list.

I support everything said above.  Here are some initial thoughts for more refined social acceptability policies:

---

Proposal 1) "blocks must include ($p percent - $o offset) of all pending transactions as measured by fees".

$p can be a low number (say, 10%), and $o could be 5, to give miners benefit of the doubt when there are few transactions available.  If many blocks pass with miners only including the minimum 10%, the backlog will grow.

Since the 10% includes the backlog, they are still guaranteed to eventually be included - they have a minimum 10% chance each block; and transactions paying higher fees will be processed faster since they're more valuable for meeting the quota.  Free transactions are processed only at the whim of miners.

---

Proposal 2)  "blocks must include ($p percent - $o offset) of all pending transactions as measured by $scoring_algorithm".

An  example scoring algorithm might be: $transaction_score = (0.001 + $transaction_fees) * $time_transaction_has_waited.

The 0.001 ensures that even free transactions will be cleared eventually; scaling by the time the transaction has waited means that minimum-fee transactions will eventually become valuable enough to clear.

---

Generally I am trying to create as little economic disturbance to the system while still enforcing some minimum inclusion.  The downside to both of the above is the $o offset will create a brief window after each new block (assuming it includes 100%) where Mystery (or anyone) can generate null blocks.  With the example 10% and 5 offset, null blocks would be valid until there are at least 50 fee-paying transactions available (assuming equal fees).  This is likely overly-conservative.  Different values or a less linear relationship (for instance, setting $o to the number of txes seen in the last 10 seconds instead of a static 5) may work better.

Since no protocol change is required, any miner can set their own values or even their own algorithm.  A heterogeneous policy would likely create a smoother response to miners' include policies, but it increases the risk of a blockchain split.  These effects should be modeled.

Edit: One additional rule may be: "all blocks must include at least one previous transaction".  It wouldn't help in a DOS situation (the miner can generate some junk transactions), but it does help with the Mystery situation: it would require miners to actually have a copy of previous blocks.  I'm on the fence whether this is a good idea or not.

Agreed on all points.

Logging IPs may not help (they may be on TOR, or communicating through their C&C network to only submit hashes from a few IPs), but if we want to try I don't think Luke's patch is the way to go.  We don't need the whole network logging everything.  We just need to get that one node to log, and there's no need to turn on global logging to accomplish this.  Coercing him by deploying a patch and hoping he applies it is a precedent that I don't think should be set in this case.

I'd say the best way to go about it is get in contact with the relay node's ISP and inform them of the situation - and be clear that this particular person isn't the network C&C, please don't take them offline.  Just have them give the owner of that machine a call and ask them to join this thread.

You can put the hash in the blockchain and prove it was taken before that block was generated.  It would be good proof to me, but proving the timestamp of that block and what your hash proves would likely be "interesting" in court.  That's a lot of math you'd have to explain to a jury.

Aside from the ethical problems with attacking someone who is probably not working for Mystery and is just a properly-operating relay node, it's not helpful in the long run.  Mystery can just start sending blocks through multiple relays.

I'm trying to ensure that miners have to actually perform the work they are paid to do - verify transactions, rather than slow down the whole network as Mystery is doing.  It's a solvable problem.

Preventing miners from using unethically-sourced compute power is a different problem.  I'm sure plenty of people will have a problem with it, but I don't see any way to solve it.  If you know a way to distinguish botnets (once they are properly supporting the blockchain) from ethical miners, let us know.

https://bitcointalk.org/index.php?topic=69423.0;all

tl;dr: There are two current proposals: 1) change the protocol to require that miners prove they have a copy of the blockchain; 2) change the relay policy to require that miners include a minimum quota of transactions.  #1 would probably solve the immediate problem and boot Mystery from the network.  #2 is a broader approach which prevents Mystery from just getting a copy of the blockchain and then still not including any transactions.  The major objection to #2 is it limits the miners' ability to reject transactions they deem unworthy, eg, insufficient fees paid.

Since the network does not appear to be in immediate danger we're still considering solutions.

I'm not a fan of IronKeys.  Just use TrueCrypt on a regular USB drive.

Inkjets are better than laser for this purpose since they don't have problems with ghost images.  Unfortunately the inks are water soluble, so make sure you laminate the pages.