Tipped.

I like it, though it feels like there's a few too many decimals. Perhaps truncate it to 3 DPS?


Also, maybe change "Last:" to be the default.

Perhaps the option of not showing "Last/High/Low/etc" next to the price, and simply have the bitcoin logo? (Since we know what price to show as we select it)

I had two: 3XX and 16XX. I'm presuming both were refunded.

I'm not based in the US, either.

Morning all, not sure about anyone else but I received 72 BTC from Tom yesterday.

I had one 54 GH/s unit and one 27 GH/s unit both paid with BTC (150 BTC paid total). Seems like the price was calculated around 24 $/BTC.

Just checking in because I received 72 BTC from Tom.

I had one 54 GH/s unit and one 27 GH/s unit both paid with BTC (150 BTC paid total). Seems like the price was calculated around 24 $/BTC.

I strongly agree with this. Most members posting here are unlikely to be unaware of social and professional ties any prominent members of the community hold.

While obvious disclosure is nice, it should be no means be a requirement.

Edit: I'm also updating the FAQ more at the moment

Oops, I hadn't made it public. //facepalm.

I believe it should work now.

I've added a paragraph about that now.

If anyone has any questions they'd like answered please quote me and I'll be sure to look out for them and try and add them to the FAQ as best I can.

I might have a go at setting one up tonight - we can do it GitHub style so other people can contribute.

Also, just a note to mention that if you're like me and only powering 1-2 bASICs you won't need the 1000 W PSU. I've bought this personally; enough room to move, but not overly expensive. (Also, I wouldn't mind if someone chimes in to double check this would be okay - second opinions are always nice)

Update: I've made the repo here: https://github.com/XertroV/bASIC-FAQ

If anyone has a spare moment please have a look over this and let me know if anything is incorrect. There isn't much there at the moment, but it should fill up over the next few hours.

Cheers

IRC might be useful for that sort of thing, but it's very ephemeral. The first bASIC shipment will be worldwide (I'm in Australia, myself) and it might be a bit difficult for people to get assistance at times. That's not saying IRC doesn't have a use here; just that it probably shouldn't be the main support line.

Tom has talked about the possibility of setting up a forum; I think that would be an excellant idea and would allow a much higher degree of moderation than either here or IRC.

That said, I don't know the degree to which people would use something like that [has anyone here had much experience with the BFL forums and the degree to which they are used/abused?] so it may or may not be worthwhile. Remember that Tom has a much smaller client base than BFL, so the cost per client, measured in both time and money, is possibly far higher.

In any case, even in the absence of a forum, I'm sure we'll find some way to communicate, either here, an ad-hoc IRC channel, Reddit, or some other forum, so I wouldn't worry too much about it at this stage (we're still a month off, remember).

Haha, well thank you (I think?)

I'm just trying to be rational about it; sometimes it seems people forget this step.

As elux was saying, there is a myriad of differences between the two companies - this is reason enough.

In addition to that, BitInstant provides services; they don't produce products. BFL do. When BFL say "we have this technology, please preorder", it is right for someone to ask for evidence (though an absence of evidence doesn't mean there are no conditions under which that is judged to be an acceptable choice); especially when it is something that hasn't been done before. When BitInstant post a photo they aren't asking for money, they're just saying "look at what we're working on", and yes, it is still right to ask for evidence - who doesn't want that - but at the same time this lack of evidence doesn't mean as much because there is less value (for the individual) in the truth of BitInstant's claim (IE: that they have a bitcoin debit card in the works).

The point of all this is not that you should or shouldn't be satisfied with what has been provided (that is, of course, up to you), but that there is certainly room for someone to not demand as much evidence from BitInstant as they would from BFL. Since such a position is not inherently contradictory the argument falls down.


It allows you to save in bitcoin and use them very easily and very quickly. If nothing else, it is moving bitcoins faster in the economy, which is brilliant.

Furthermore, yes, bitcoiners need to talk to others about Bitcoin (and the bitcoin) and encourage them to accept the bitcoin as they do money other currencies; however, in the mean time this is an excellent compromise - it, at the very least, sponsors the movement of bitcoins through the economy (albiet in a needlessly complex way that involves fees and such and so is not as good for the economy as 'true' business in bitcoin), which is better than not at all.

What's the point? It is a bridge. Something that is useful to the bitcoin economy, but not as good as we'd like. Process is important, and this simply helps that along (for an analogy, think of why "half a wing" is in fact useful evolutionarily).

Anyway, just my 20 mBTC

The only thing required to keep the Bitcoin project community driven is the knowledge that the network has the power.

If the Foundation becomes evil they can no more change Bitcoin than any of us, as long as we remain mindful and informed. Keep electing prominent and trusted members of the Bitcoin community and that should not happen. (Even if it does, the Bitcoin network can happily work quite well without the mainline client)

Does anyone know who exactly constitutes the "Founding member class", and if this group is already fully set?

Looking forward to the bylaws being posted.

And I'd like to voice my support of some automatic confirmation.

I'm now a lifetime member, too. Glad to see this happening.

Is there any chance of this being able to support blockchains made using a different version of libdb?

Also, the PPA is most certainly updated.

Thanks, --force-online would be fantastic!

I ended up changing line 890 (I think, I added some proxy stuff to where it tries to get the HTTP_VERSION_FILE, which didn't seem to help that much; point being the below is 894 on mine. It's around there in any case) to be

That worked. Curiously, when I started it at some point I checked the log file and it was saying it could indeed connect to both bitcoin-qt and the interwebs. So I'm not sure what was going on there (I was fiddling with Ubuntu's system proxy settings, so that might have helped too.)

I didn't update at the time due to the market, but it was a quick and simple fix.
The other reason why --force-online would be nice is if you use connect= or addnode= in bitcoin.conf to access a node on your LAN with internet access / port forwarding if the client doesn't have direct access itself. (so Internet <-> gateway node <-> client node + armory). In those cases I imagine you could send/receive transactions fine, but you wouldn't have internet access yourself.

In any case, it's all good now.

I'm also running it in a VM because OS X isn't supported. I'm using Mountain Lion atm and will keep trying to compile Armory in my spare time (Lion instructions don't seem to be working too well ). If I can figure anything out on that front I'll be sure to post it (oh, how nice a .app would be! To the computer box!)

I've got a small bug report / request (it's only a bug in very particular network configurations, like my Uni's).

It seems that when Armory loads it now attempts to download a file (versions and whatnot)


Setup for uni:
Need to VPN to get NAT, otherwise only web access is allowed.
This is done through proxies, but these proxies must be preset ALWAYS. Port 80 is always blocked out (the only exception is the wireless network, which has transparent proxies - now), this means that while Bitcoin-qt is happy and connected, and Armory can talk to Bitcoin-qt, it fails to connect to the internets and so fails to start.


With few exceptions every other port is available.

My 'feature request' I suppose would be to enable support for system proxies, or set up an arbitrary port (like 39462). I don't know which would provide greater compatibility.

I'm going to try my hand at creating a patch for ArmoryQt.py, and will post if successful.

(BTW, Thanks for Armory, Alan!)

Updates: I've run another bitcoind (with -datadir) to a fresh directory, and I this bitcoind downloaded all the blocks without any fuss. This is nice since nightlies weren't working too well for some reason.

If anyone else has this problem this is a potential solution.

In the new dir you have to setup bitcoin.conf with port= and rpcport= [pick two numbers other than 8332 and 8333] set to avoid port collisions. Then also put in an addnode to your already running client:


That way it will download the blockchain quite fast (faster than I get on 100mbit/s internet; though I've got an SSD too) and will be happy to download past the stuck block.

When I read halfway down the first page I realised it was exactly what I needed. I've been thinking about the idea of having a private key to some GPG encrypted information stored in such a way that you only need say 3/5 keys to decrypt the information. That way, you can communicate from inside an absolutely sealed environment and save things like passwords or details of assets and projects and particularly bitcoins, and save all that information with a measure of security but entirely outside of your control. By holding on to one of the keys yourself, perhaps a crucial key, you could ensure nothing could happen while you were alive. I want to experiment with a 2-tiered system, as in you need [3/5 root keys], or [2/5 root and ANY 3 of like 8 secondary keys]; that is that the secondary keys are not particular to the lost root keys.

Anyway, don't mind me.

Subbed.

• Detachdb is always on for me (so I can copy the blockchain more easily)
• Backing up now, will PM you with a link (so I don't run through all the bandwidth); if anyone else needs a link please let me know [or maybe torrents would be a better idea; I'm on a 100mbs connection here]

Update: PM'd

Update2: I noticed that Armory stayed up to day until I started using a new datadir (mv'd old one and set up a symlink to make future experiments easier). It now registers from as far as bitcoind has downloaded. I ran into an issue where new blockchains would not have a blkindex.dat and bitcoind/-qt would try and download from block0 but would APPEND new blocks to the blk00002.dat. So even though blk00001/2.dat existed, they were ignored. Didn't get a crash or exception so I presume that it's not a libdb++ issue.

The point of all this is it might be the case that bitcoind/-qt WAS downloading new blocks, but just not processing them! Maybe.

Using Bitcoin-Qt (and bitcoind) v0.6.3 from the PPA [Ubuntu 12.04 x64].
Have tried launching a freshly compiled Bitcoin-qt also.

Despite this and a -rescan, the client doesn't seem to want to download past blk 192528

I use Bitcoin-qt just to downloads blocks with an unused wallet.dat. I run it with Armory 0.81-alpha attached.

Strangely, Armory seems to be downloading new blocks fine. It also registers new transactions (after 192528). The height currently is 192885 which matches blockchain.info.
However, from Armory I cannot broadcast transactions to the network - but only from select wallets. I presume this is because Armory tells my client that a transaction is taking place many blocks ahead (in terms of transaction balances) of where the official client thinks it could be; I cannot send coins from an address which has only received coins AFTER block 192528, however, an address which has held some value since at least block 192528 will generate an accepted transaction.

Resources I've found prior to this:
https://bitcointalk.org/index.php?topic=78307.0 [happened april 23ish]
https://github.com/bitcoin/bitcoin/pull/1196 [apparently fixed the issue]

Anyone have any ideas? I'll try not re-downloading the blockchain for a little while so any debugging/info gathering type thing needing to be done can be.

As long as this happens I'm a happy camper - helps us and the bitcoin economy.

Thanks for the update, DeaDTerra.