Finally got around to adding the compressed public key support required to recover wallets created by Bitcoin 0.6 and up. windows version?
Afraid not, sorry. |
|
|
|
Indeed. But if someone were to spend the time and money on an ASIC run, wouldn't any altcoin be at risk? Not really. Litecoin is scrypt-based, and if you read the original paper on scrypt its main design goal was ASIC-resistance. More precisely, it was designed to limit the efficiency gains you can get from moving from a general-purpose processor to an ASIC. You can build a Litecoin ASIC quite easily, you just won't gain that much speed or power efficiency compared to using a CPU or GPU. (Solidcoin's hashing algorithm, on the other hand, doesn't have the same kind of ASIC-resistance. They can just change it whenever they like though.) |
|
|
|
Rebranching from latest Bitcoin... does it mean we will get BIP16 (multisig) as well?
I think it required some careful planning and support from pools before it was fully enabled in Bitcoin.
Yes, it does. I will look into it. For now you should be able to just soft-disable it by changing the "true" to "false" on line 498 of init.cpp: if (GetBoolArg("-bip16", false)) |
|
|
|
You forgot that everyone who has BTC will loose it all when we switch to another alt-currency/hashing function. Also, if everyone switches to an existing chain like Litecoin then anyone who's already holding that currency will make money. That might be a good way to profit from attacking Bitcoin actually. |
|
|
|
D) The code is a bit strange, several things are... Wierd... in it. And it causes some problems, such as the boundry between clock domains between the comms code and the hashing cores, this causes in the default setup a clocking breakdown and the comms core fails, leaving the chip useless until it's restarted. There is also some over-sensitive settings on the hashing clock, which is why we had to underclock it to 50Mhz (over that the clock becomes unstable), which since the icarus code runs one hash per clock, that means 50MHash per chip. And a few other issues. Essentially it needs A LOT of hand holding to get it into a useful state at all. There are seperate clock domains for the comms and hashing? Interesting. I hadn't really looked into it but was under the impression that the Icarus code was based on teknohog's clustering code and used a single clock domain for comms and hashing. |
|
|
|
Except thats not what happens either. Please do a bit of research; this topic has been covered quite well already on this forum. Keywords "Dash7" "Jabber" and "XMPP" should help.
Dash7 apparently solves the problem by not routing data any further than 2 hops. So if you're more than 2 hops in the mesh away from the node you're trying to communicate with, you can't send or receive messages to it. Jabber/XMPP is a client-server protocol that assumes all servers are directly reachable by all other servers. |
|
|
|
Psion
A dynamicly updated routing table, or a routing table at all, is not a likely condition of this kind of network. Sensor style networks use passive monitoring to detect reachable peers on the fly, and it's a completely different model than a network that is trying to emulate the mass data transfer capabilities of a wired network. A bitcoin transaction doesn't need to be routed, it simply needs to be broadcast.
Well, you can use flooding but that doesn't scale either. Imagine if, every time someone in New York City made a transaction or sent a message, every single tiny, battery-powered, low-bandwidth node in the city had to wake up and forward it on. You'd run out of bandwidth and kill your battery life with even small amounts of traffic. |
|
|
|
Mesh networking isn't implausible at all, hams do it constantly. That is exactly what a packet TNC does. The real question is can they do it in such a small device and with such small power requirements, but 100 meters is nothing for a modern digital mode even at low power levels, so I don't consider that unrealistic either. In fact, I'm hoping that they are under stating the effective range, because 100 meters isn't practical except in some pretty dense urban areas. I'd say the bear minimum effective ranges start at 300meters. And nor is communications sans (commerical) infrastructure implausible, for that is the very nature of mesh networking anyway.
Packet TNCs are set up at fixed locations and use manually-configured routing though, right? That's not mesh networking in the sense we're talking about here. The hard part of this kind of mesh networking (I believe the technical term is "mobile ad-hoc networking") is dynamically-updated routing between a bunch of small moving devices, all of which has too little memory and compute power and bandwidth to store a full global routing table. Normal mesh networking is similar but has stationary nodes that are typically more powerful. |
|
|
|
On ZTEX boards, the FPGA's JTAG signals are not even connected to the Cypress FX2 microcontroller.
That's unfortunate. I'm guessing he's not broken out the appropriate pins to allow the two to be connected either. |
|
|
|
Well, if this is true. The CEO of BFL (or the VCs who may be able to replace him) can own the network at trifling cost and there is jack shit anyone can do about it. You deluded idiots and your precious decentralization. What a fucking joke.
Well, yes, sort of. This has always been true. Didn't have to be BFL of course, but it was obvious for a long time that owning the network was within the grasp of anyone with a decent amount of money who could get ASICs designed and manufactured. However, as several people have pointed out already, what you need to bear in mind is that even if this is true we don't know how many THash/s worth of chips BFL would need to sell in order to reach this kind of pricing. We can guess, though, and it's not likely to be a small amount. Once you factor in that and the resulting increase in difficulty those prices will probably look rather less attractive. |
|
|
|
"Bitcoin is the cheapest way to send somebody money"
Whether that's true depends on what 'money' is understood to mean. If 'money' just refers to bitcoins, then, yeah, that's probably true. But if what's meant is that it's the cheapest way to send somebody, say, USD, then no, it's very unlikely to be true considering the fees to transfer money to an exchange, then buy the bitcoins on the exchange for a fee, then send the bitcoins, then have the other person convert back to traditional currency. I haven't done the math, but I'm willing to bet that for most transactions, that whole process is a lot more expensive, and probably not that much quicker, than sending somebody money through a bank.
Even if you're not exchanging to USD on either end, it's still probably going to be more expensive in practice because of the higher prices of buying items in Bitcoins as opposed to USD. If you think about it, pretty much all the commercial sellers offering goods for Bitcoins have to immediately exchange for USD since that's what they paid for the goods in, and they'll want to take an extra cut on top of that to compensate for exchange rate risk, plus Bitcoin is a small market with not much competition, etc... |
|
|
|
If you're sending commands to urjtag over a pipe, don't forget to disable urjtag's command history. Otherwise it seems to store every single command sent in RAM for the duration of the session, so its memory use slowly bloats. Also, I seem to recall there's code out there to emulate the Altera USB Blaster JTAG adapter using a Cypress FX2 like the one on the Ztex board, e.g. http://fpga4u.epfl.ch/wiki/FX2. No idea how practical it'd be to port it though. |
|
|
|
But that is the problem, I've actual photos of Bitcoincards. Granted, still photos can be faked; but I have nothing at all from you concerning the Ellet. From my perspectives, it's the Ellet that is vaporware. At a minimum, the Bitcoincard guys have working test models. I saw a youtube video of two such cards (sitting less than a foot from each other, mind you) perform a transaction on video. A transaction that can be verified via the bitcoin blockchain. If the bitcoincard is vaporware, the fog is getting pretty thick. You sure about that? As far as I'm aware, all the stuff they've demonstrated so far is entirely technically feasable if a bit tricky. It's actually the claims which they haven't given any demonstration of so far - the solar recharging, the mesh networking, the usability of the cards in areas with no infrastructure - that are implausible. Each of them is a major advance on the state of the art on its own, and combining them is harder yet. (Not Matthew N. Wright, but this sort of thing stands out like a sore thumb.) |
|
|
|
Hopefully it's powerful enough to run P2Pool.
Doubt it. P2Pool's quite RAM-hungry and it requires running a full Bitcoin daemon which is fairly IO-heavy. Remember that by default the Raspberry Pi only has 128 MB of RAM available to the CPU, which can be increased to a maximum of 224 MB if you're willing to essentially disable GPU acceleration (presumably you're not using that anyway). |
|
|
|
Why they use this odd plastic packages if these FPGA's are also intended for extreme applications (like bitcoin mining)? At 12W the temperature difference between die and heat sink would be about 26°C in CSG484 packages (I use) and 44°C in FGG484 packages (used by other board vendors). IMHO this is not optimal. That quote's from a thread about a Virtex-5 device. As I recall those have metal heatspreaders. So a different chip, different packaging, and built on a different process (65nm rather than 45nm). |
|
|
|
Xilinx guarantees their chips can tolerate operating junction temperatures up to 125°C (see page 2 of DS162) without damage, for all temperature grades (they're manufactured identically, then sorted by testing). That's the Absolute Maximum Rating. If you look at the footnote it warns: "Exposure to Absolute Maximum Ratings conditions for extended periods of time might affect device reliability." So they guarantee it won't die immediately, but not that it won't eventually fail in a few weeks or months as a result of running it out of spec which is what ztex is worried about. |
|
|
|
So now this uber light and slim card needs a dongle to function properly? The vapor thickens.
And the maximum range of the dongle is 100 metres according to the website. Presumably the card-to-card mesh communications will have, if anything, an even shorter range. I can't imagine this working terribly well somehow. Most likely the "mesh" functionality will end up being something that looks good on the spec sheet but isn't actually practical - at least not for Bitcoin payments - and the entire thing will be dependent on the fixed access points to work properly. |
|
|
|
|
Oh my. I think I may have an idea what this is all about, and if I'm right this attack would be scarily easy to implement.
|
|
|
|
1.2.4 Trading is a positive zero-sum game
Rational Traders will not play a true zero-sum game in which they only value trading profits. If all traders were all alike, all expected returns would be zero and no one would benefit from trading. If some traders are more skilled than others, the skilled traders would want to trade but the unskilled traders would not. No one would trade. This assumes that traders are rational, and in particular that they're able to rationally assess their own skill level and correctly attribute any gains to either luck or skill. The available evidence rather suggests that isn't true. It also fails to account for the principal-agent problem - if traders are getting large bonuses for making profitable trades with their employer's money, they have an incentive to make trades that would make no rational sense if they were the one that stood to gain or lose directly. |
|
|
|
|
Show Posts
