Luke-Jr: So you are saying that computers "are supposed" to be exposed to the internet with all these worms and such auto-infecting any computer it stumbles upon by attacking random IP adresses? Yes, computers are supposed to be connected to the internet. And people are supposed to keep their systems secure. Possibly run a firewall, if they're a target or for extra piece of mind. In the past, the security of NAT was really not necessary, but in the today era, NAT is a essential security that provides inbound protection. Without a NAT or some sort of firewall before a computer, the computer would pretty much get totally owned in about 15 minuters of connection of to the internet, even if you are not touching the computer. NAT is not security at all. In theory, NATs *should* pass all inbound connections-- most just don't know how. A firewall is something completely different. If the user has a firewall, UPnP should not override it. UPnP is to fix the flaw that NATs don't know where to forward connections, nothing else. |
|
|
|
|
More FUD. UPnP is not a security problem. NAT is not a security mechanism. If someone can exploit Bitcoin to send arbitrary packets, UPnP support is not going to make it much easier. UPnP is a hack to fix a hack (NAT). Neither should have ever existed, but UPnP brings things back to how they are supposed to be normally.
|
|
|
|
|
Overall, it looks video good. A bit too fast, IMO, though-- I had to skip backward to keep up a few times!
Only other suggestion I have is to mention tradebitcoin.com on the webpage.
|
|
|
|
If you're saying that storing base units in a 64 bit integer internally is a bug, how so? No, I was saying the opposite (storing values as BTC) is a bug. Perhaps I misunderstood you. |
|
|
|
|
Theory: part of the problem is that MtGox market is assumed to be the value of BTC. As more people are trading outside of MtGox (plus the difficulty in getting MTGUSD), that market has grown less stable, bringing it down. So Bitcoins might be retaining their parity value (or slightly below) in practice, but the effective canonicalization of MtGox market value makes everyone feel it is less. This results in buyers not wanting to pay the asking price, leading to less movement overall, and it all spins downhill...
|
|
|
|
Detecting display type based on amount would be easy, but I am storing the value as decimal base units no matter what is entered for ease of interoperability with Bitcoin's JSON-RPC. This is a bug. You're right though, I should divide the decimal amount by 65536 before converting to hex, correct? For some reason I'm having trouble wrapping my head around that, though the math seems to work. Yes, and be sure your hex-conversion function can handle fractional values (eg, 0.1 TBC). I'm not sure about displaying actual tonal characters, I think I will keep it displaying their hexadecimal equivalents instead. Are there even any fonts which include tonal 9-f? That could be confusing, since Tonal is not Hexadecimal. '9' Tonal is 'a' Hexadecimal, and '9' hexadecimal is '' tonal. There are at least 3 fonts that I know of: http://luke.dashjr.org/education/tonal/glyphs/fonts/ |
|
|
|
|
Since you are already factoring out libraries, I would suggest doing so with the formatting code too, possibly adding an abstract function to autodetect display type based on amount.
I don't use Windows/Mono, so I can't check for sure, but I suspect the TBC rendering code has a few bugs... It seems to just convert amount to hexadecimal and stick TBC on the end. If so, this is missing the tonal point (1 TBC = 10000 (65536) Satoshis), and neglecting the fact that tonal has different digits than hexadecimal. If .NET has a Unicode-compatible tr(anslate) function, you could map "9abcdef" to "".
Interesting concept with the ScientificSatoshis
|
|
|
|
|
I'm offering 50 BTC to the first only-open-source miner to achieve a minimum of 252 MH/s (that's 95% of my present 265 MH/s) on my Radeon 5850. To claim, please send me an email at luke+openminingbounty@dashjr.org with the SHA256 hash of your miner tbz2, in case this turns out to be a close race.
Edit: This offer is expired.
|
|
|
|
|
IMO, the whole point of having scratch-off cards is if you don't trust the person handing you the coupon. I don't see any way to fix that short of having a (or many running the same open-source webservice) central trusted authority issuing the scratch-off cards.
|
|
|
|
But you still need to know when the coins arrive right? Orders can be verified/filled by a system without any external services (eg, only port 8333). I don't know the crypto side of things-- is it possible to create a half-key which can be combined with another half-key? So for example, the webserver can customize half the key per transaction (leading to unique addresses for the customer), but not have the information to spend that tx until its half-key is combined with the locked-up-safe master-half-key... |
|
|
|
I'm getting 280 khash/s while overclocked to 1150 Mhz. Not bad at all.  If you want to fry your N900 in a matter of months (at most). |
|
|
|
The HTTP error codes are encoded into the JSON. But there are other errors like wrong username/password combination or status updates like new address added. You can't use HTTP header codes for those. Sure you can. 401 and 200-202 look appropriate. |
|
|
|
|
IMHO, the top should have 2 download links: one that is the "default" client for the user's platform (identified by User-Agent), and the other linking to a table of alternative clients/platforms.
For example, on the main page:
[ Download wxBitcoin for Windows ] | (Download other clients/platforms)
And on the second page:
Client | Win | Mac | Ubuntu | Deb | Fedora | RH
----------------------------------------------------
wxBitcoin | D/l | D/l | D/l | D/l | D/l | D/l
BitcoinD | D/l | D/l | D/l | D/l | D/l | D/l
Spesmilo | D/l | D/l | D/l | D/l | D/l | D/l
...
|
|
|
|
Usernames are case insensitive and can contain any character. Why not leave that up to the server to decide? The POST queries return a JSON. If there's a key by the name of "status" then it was successful and the value will give you an update as to what occured. If there's a key called "error" then it was unsuccessful and the value is an error message. The JSONs can also have other entries depending. Is there a reason not to return either a 302 Found pointing to a bitcoin: URI, or else a standard HTTP error? I don't see why this needs JSON at all... |
|
|
|
|
Reasons to use HTTP over DNS:
1. Compatible with cheap webhosting available anywhere
2. Can generate new addresses (or pull them off a list) for every transaction
3. Can be provided a comment, invoice ID, or from address to save in a database (associated with the generated address)
|
|
|
|
Learn from FreeBSD and other decent OS. Stuff is off by default. Stuff opening ports to world wild web is definitely off by default. Erm, no. Services may be disabled by default, certainly, but once you start (for example) Apache, it listens to port 80 by default. You don't have to jump through extra hoops to configure a port. Likewise, distros won't auto-launch bitcoind by default, but when the user does so, they should reasonably expect it to listen. An unfounded possible vulnerability is no excuse to make things harder for the user than they have to be. There could just as well be a vulnerability in the transaction code, or anywhere else that is going to be exposed to all nodes regardless. If you don't trust the bitcoin wallet you're using to be secure, you shouldn't be using it period. |
|
|
|
|
This would make for a good replacement for IP transactions, if it is specified to support comments (can be used to say who it is from, or what invoice is being paid) and uses SRV records. Unlike IP transactions, the simple HTTP nature allows people to just upload a script with a pre-defined list of addresses and write the comments for each address, using a stock web hosting service...
|
|
|
|
It's pretty much finalized, and in real world use (IIRC, mainly in phone UIs) |
|
|
|
|
Show Posts
