Status update: sent this morning, tracking code provided to fulepp... now we wait

That's ok, their sold anyway

@fulepp: received. As I had told you I'll send today and will provide tracking number.

@everyone else: Communication along the PCI express is hardly the bottleneck with current generation GPUs (when mining). I have ran 4 x 5970 (that's 8 GPU cores) on another board (an ASUS, can't remember the model) using 2 full length PCIe (at 8x) and 2 1x ports, without any performance degradation, though that was an LGA775 board.

I have an agreement with fulepp to sell him:
- 3x 5870, one XFX, 2 Saphire (one of the latter has issues with the fan at low RPM, but has been working fine at 90%)
- 1x MSI 790GX-GD70
- 1x AMD Sempron 140 with stock cooler

All the hardware is working great except for the fan thing mentioned. All cards have the BIOS tweaked to allow lower memory clocks (150Mhz) and all are doing at least 940MHz stable. There's plenty of dust on the cards, but I'm not charging extra for that

Price agreed is 100btc, shipping included. fulepp will pay me 70btc first, and the other 30btc will follow in at most 30 days. Once I receive the first payment I'll ship with tracking.

Payment can be done to address: 1PE3R2ADah8EJ16fp5e41BR86me27sNPFK

PS: The 'magic ram speed', as best as I could find, is 190MHz.

I would argue that this kind of functionality is *exactly* what the default client should do, and less of the UI handling which is better left for the UIs

But I'll have a look at stratum, thanks for the pointer!

I hope this wasn't covered before, couldn't find any references (but didn't look too hard)...

BitcoinSpinner is a great mobile client, but the real magic happens underneath, in the BCCAPI server that has the blockchain and the pub keys, but no priv keys. It can then prepare transactions but the client, holding the priv key, needs to sign and resubmit to the server so it can then push the signed transaction to the network.

This has many advantages for web services, such as removing the need to either have a separate bitcoind with a full blockchain for each service or share a daemon/blockchain but also the risk of holding all coins together. Also makes upgrading the server much easier, and allows the private key security to be handled by the web app coder instead of the sysadmin holding the bitcoind instance(s). I *really* like this, but I don't like running alternative bitcoin daemons for web services, especially when I can't easily review the critical code or trust that a lot of other people has done so already.

What would it take to allow for this workflow on top of the bitcoind RPC mechanism? All the getbalance is there, we'd need afaict:
- add public keys / addresses
- request a transaction blob
- document (create examples in whatever languages) how to properly verify the transaction blob actually matches what the client requested from the server
- document (as above) how to properly sign the transaction
- submit signed transaction back to server

With this not only would open bitcoin servers be possible for alternate clients (even the standard one?) thus removing a lot of the initial pain for new users (less bloat, much lower initial bootstrap time) but more importantly would make the web service designer life much, much simpler.

Can it be done? Has it been done while I wasn't looking?

I'm buying yubikeys, so if you have a mtgox yubikey you don't use or a generic one, I'll give you BTC 1.5 for each, shipped to Portugal.

I would be interested in this, assuming what I read about the iPads not being carrier locked (unlike what you describe). If you could try a diferent carrier SIM card just to make double sure that would be super.

I'm willing to give you 100btc shipped internationally (to Portugal), but I will not give anything up front. I'll gladly use an escrow, we can ask a forum member that is well trusted (see https://bitcointalk.org/index.php?topic=37805.msg464209#msg464209 for some options, davout has agreed to escrow in the past) or, if you trust me, I can pay on receiving the iPad.

I do prefer to keep the negotiating on the thread instead of PMs, if that's ok with you.

I have 4 5870s, but I do want to keep one for gaming. I know 2 of them are XFX, can't remember the rest. One of them (non XFX) has the fan misbehaving, so I might keep that one and sell the others. I will let you know the exact makes soon, but what price range are you considering before I start tearing my miners apart?

Why not the lowest daily weighted average for the period? Should be approx the same as the lowest value, after odd spikes are averaged out. And when you say non-binding does that mean either of the parties can just decide to not go through with the deal at maturation?

As someone else pointed out to me, why not use http://nothingsteamed.com/beta/ ?

Which is on sale for the next 5 hours: http://store.steampowered.com/app/31170/

Anyone wants to sell me a gift? Will pay in BTC.

I still feel that import should be a feature embedded in the main client, even if only when compiled with special switches and/or limited to the RPC. This is something I see as very important for my business ideas, but only as part of a server infrastructure.

When it comes to the client side, the GUI, then I most certainly think that import could be completely avoided by the use of sweeping. I would even argue 'KISS' and no auto resweeping should be implemented... if you know more funds are going that key way, just resweep it yourself. Since the block chain is already in the client and we can know what balance exists in that key, we could completely skip the importing and thus display of any transaction log related to the swept key, which would make things very clear to users, even the "lower grade" ones.

+1 for getting sweep in asap, it will make things easier for everyone. The only thing missing then is the (very dangerous) ability to export a private key without keeping it in wallet on the UI, so users can generate an address to send someone (like bitaddress.org does using JS), print QR code, email, whatever and then simply send funds to that address.

We can already do that last part using external tools, but these are prone to a number of attacks, scams and the like. If 'regular joe' is able to send dad some funds using a private key he generated, we'll start seeing a much, much easier way of giving away bitcoins *before* educating people about it... perception of value:

- Hey, why don't you go to this website, read about this new uber crypto pseudo-anonymous currency, browse the forum where many, many users are talking about scams, crypto algorithms, FPGAs, scams, politics and scams, then install the software, wait 2 days for the block chain to download, generate an address for me which by the way will keep changing in the UI and I can try to explain why but without knowing the basic concept behind this it will all sound very complicated and THEN I'll send you 10 btc to get you started.
.. versus ..
- Hey, here's a voucher for 10 bitcoins. You already have the "cash", now you just need to <insert hoops to jump here>.

So while the effort is exactly the same, the latter gives you the value immediately and you are much more likely to jump the hoops

This might be a bit off, as I'm not sure about the implications, but what about a 'not known' timestamp, always displayed on top by first come order? It could be shown as current timestamp (read, changes as seconds pass) which would be cool and confusing, but most simply not showing any timestamp until transactions are assigned to a block and using the block time from then on?

Outbound transactions, the ones we send, could benefit from keeping the actual transaction creation timestamp, but even then I'd be plenty satisfied if I knew the timestamp of the block in which they got included.

Yes I can. It's just hard to do so without giving away too much of a potential project idea, but better support trumps business secrecy any day in my book so; I have a storage of priv keys, generated offline, and I need to hot include these on a running server. Now mind you I own these keys, I generated them myself, but they do not exist in a wallet, that would be VERY impractical.

I could take the server down, use pywallet, start with -rescan. But I don't want to HAVE to batch imports, meaning a rescan for each key. Because I know at which time point the key was first used (and most times it will not have been used at all, thus no -rescan is needed), and that is very easy to find when unknown if the blockchain is properly indexed, so I can request a rescan from block nr X.

This is the one case I have where sweep would simply not fit, but for every other case I've come across and use a custom patched client for, sweep would be just fine. Though sweep with an option to keep the key in the wallet but *not* resweep would work just as well.

Agreed, except those doing web services that might depend on this feature are left with either non-official clients or patching the official ones, which gets complicated to maintain in a stable, well tested way.

A product with both 'foolproof' and 'powerful' is possible in theory. Let those that are capable of compiling switch the 'advanced' mode on, though of course there will be someone sending ready built 'advanced' versions to foolish users.

Make it a configuration that you have to edit by hand, and make the first run of the client show a bit red flashing 1999-web-page-like dialog stating they WILL screw up eventually, so be careful.

Not giving the option by default is a smart move, maybe even only give using RPC to start with and see how inventive users get. But not giving the option at all because it might be dangerous... I gave a user an address for him to send me 70 coins for some stuff I sold... but I gave one of my *sending* addresses instead of *receiving*. I was stupid, but what allowed this to happen? Was it the copy to clipboard feature? The address book? Should we get rid of both?

Nope, they have no way of knowing, they said. The service expected time is "up to 7 work days" like I told you, but that is all I have.

I have send the package a little over an hour ago and have provided dmcursor with a tracking code. Hint: avoid going to the post office close to xmas

davout: which key did you use to sign that message? Your support@bitcoin-central.net doesn't match if I'm doing things correctly here.