I lost tons of Bitcoins when BTC-e was cracked.
BTC-e returned ALL my Bitcoins AND USD, from his own pocket, within 6 hours.
This is how a honest people run a serious business.
You guys must learn with BTC-e and with this crazy (in a good sense) Russians, before talk shit...
They stole pocket change from me, and refused to even respond to my emails. A company that steals pocket change far from honest. |
|
|
|
I someways making the transaction un-prunable is better for messaging, but I understand your concern.
One way to do it could be to use an M-Of-N 1 of 2 multi-signature transaction and have the 2nd public key as the message. The tx would then still be spendable with the first public key, but not many clients would be able to redeem it. I'm open to suggestions? Embedding messages is really abuse of the (main) blockchain, which is for currency transactions. The correct way to do this is to setup some merged-mined data that ties the message to the transaction id, and distribute the message as <text>,<txid>,<merged-merkle-links> |
|
|
|
Some orphans now from people with horrible connections.
I know blockchain.info is missing tons of IPs and isn't very accurate, but if you see an orphaned block that was only relayed to a couple nodes, then you know there must have been a good 10-15 seconds in there before it was broadcast.
Why not use a p2pool with a decent connection that'll have a nice up-to-the-second bitcoind? It wouldn't result in any more rejects or orphans, would it?
Hmm, unless the problem is a bitcoind that doesn't allow incoming connections and only has 8 outgoing (and not to any good nodes).. time to make use of addnode? Might I suggest 5.9.24.81? My max is 1000. There is a known problem with Bitcoin relaying blocks. Every step of relaying a block, the node needs to 1) finish downloading it completely, 2) verify the block header and ALL transactions are valid, and 3) upload the entire block to the each peer node in sequence. The obvious (but very non-trivial to implement with Satoshi's codebase) solution is to parallelize block distribution; that is, as soon as you receive the 80 byte block header: - verify it is
- a valid header
- the header for a block after the most recent one
- meets the required difficulty
- immediately send all peers the "incoming block" message
- upload the block to peers as fast as they can take it, as it is received
Then, distribution is accomplished in realtime, and all the bottleneck remaining is restricted to verifying transactions locally on each node. |
|
|
|
Also will CVE-2012-4682 and CVE-2012-4683 be fixed in 0.7? Thanks to Sergio Lerner for reporting denial-of-service vulnerabilities fixed in this release. These are the same. No, since CVE-2012-4682 and CVE-2012-4683 have different numbers, they are new vulnerabilities fixed in 7.0rc1 by the dev team. It's my understanding that you reported multiple vulnerabilities fixed in 0.7.0rc1, each of which is assigned a different number. |
|
|
|
Please provide evidence for everything you have said.
BTC-e is operating legally (per Russian, Latvian, and Cyprus law) and I have all corporate information regarding them. I am willing to testify that BTC-e has stolen funds in accounts banned without cause or recourse. |
|
|
|
"BTC-e Bitcoin Exchange is not a registered business , is evading taxes , is evading the law by using a non registered currency , has sold the source code of their website to a known russian Ponzi Scammer , outright lies and falsifies police reports , threatens users , closes accounts with people's funds in them and never allows the funds to be refunded and censors and unfairly bans people from their chatbox going against The Freedom of Speech." I'm all for going after BTC-E for legitimate crimes, but I'm not aware of anything illegal in "using a non registered currency". And "freedom of speech" only restricts the actions of certain governments that guarantee it, not those of private businesses. |
|
|
|
I see BIP 0034 is listed on the CVE page. Is it actually to fix a vulnerability? The listed BIPs are there because they effectively create vulnerabilities in older pre-BIP clients. That is, the fact that these old clients accept blocks that are (now) invalid, is a risk. Also will CVE-2012-4682 and CVE-2012-4683 be fixed in 0.7? Thanks to Sergio Lerner for reporting denial-of-service vulnerabilities fixed in this release. These are the same. |
|
|
|
Mining majority is not the same thing as economic majority. Mining majority is actually harder to achieve provided you are Gavin and your client, solely under your control, is by far the most popular. Or isn't it any more? In any case he'd need at most the collaboration of 2-3 key people to achieve that. The economic majority can always choose to not upgrade. I know if Gavin did something as absurd as changing the algorithm without good justification, I'd be willing to support a fork, and I doubt I'm the only dev who would. Edit: I highly doubt Gavin would attempt such a thing, btw. |
|
|
|
Also, imagine that Gavin's September announcement was a change in the mining algorithm. LOL. Gavin doesn't have that power. A change in the mining algorithm would require support from the economic majority. There's not too much chance of that happening. He can propose though. In the past he's always pushed his proposals successfully, with or without opposition. Only 4 or the top 5 pools required at the moment. Maybe there's plenty of FPGA mining power there though, not sure how would they adapt to a potentially new algorithm, even if still SHA based. Mining majority is not the same thing as economic majority. |
|
|
|
Also, imagine that Gavin's September announcement was a change in the mining algorithm. LOL. Gavin doesn't have that power. A change in the mining algorithm would require support from the economic majority. There's not too much chance of that happening. |
|
|
|
Is transparent possible?  |
|
|
|
Just a quick update to let everyone know the plans for BFGMiner 3.0: - ASICs! Or at least whichever of them are ready in time for the release. Planned:
- FPGA Mining X6500
- Next-generation getblocktemplate decentralized mining protocol, to satisfy the hashrate demands of ASICs
- Improved Ztex support, now that I have a pair (x and y)
Support for getblocktemplate will be powered by my new "libblkmaker" library, currently in development, written in C for maximum portability, and licensed under the MIT license so other mining software authors can take advantage of it. Anyone who wishes to contribute to its development is welcome to do so (as with BFGMiner development, for that matter ). I'm open to adding support for any other devices simply by providing me with one for development, testing, and ongoing maintenance - just PM me.  |
|
|
|
Changing the algorithm would only benefit the few big money players, who can build a new ASIC chip fast, and hijack the market. As long as that is true, it's obviously not going to happen. The risk of it happening only comes with someone having ASICs online before anyone else. Luke just doesnt want to move to litecoin with his GPU's when they are made redundant  Quit putting words in my mouth, kthx. |
|
|
|
Mining majority cannot change the algorithm... This isn't entirely true. ... Replied on the other thread. |
|
|
|
Mining majority cannot change the algorithm, only an economic majority can. I don't think anyone would be able to get most BFL miners to switch without a good reason, anyway - it's simply too risky since "greed" won't fly with the non-BFL miners. This isn't entirely true. As I know you're fully aware, if an ASIC manufacturer with much greater than 50% of the network hashpower has implemented some new secret hashing algorithm, they can declare that the Bitcoin network is switching to their new algorithm and that they'll use their 51% to prevent any transactions ever confirming for users that remain on the old one. They can't force everyone to change to their algorithm, but they can render the existing one useless quite easily. As soon as BFL ships the ASICs, they have no control over them. Their own customers will be securing the network against such an attack. If they tried to pull off such an attack before shipping, the Bitcoin community could just switch to an algorithm their chips don't support. |
|
|
|
No, that reply didn't really address the concerns he brought up. You stirred up the hornet's nest with this unsupported assertion: ASIC vendors are advised to implement an alternative algorithm ... There's no reason this statement of fact should be controversial at all. |
|
|
|
I'd appreciate if people would stop trolling and putting words in my mouth. midnightmagic raised some important points, and as an investor I think they should be fully taken into consideration. It's really that simple. |
|
|
|
If anybody is interested in a lottery that pays 5,000 BTC jackpot for 0.10 BTC per bet, please let me know.
Can I bet on every possibility for under 5kBTC? |
|
|
|
- The backup algorithms would only be useful in a scenario where SHA256 is not itself broken, but a single miner with the "cannot easily change algorithm" weakness is doing something harmful (such as forcing the network to trust them).
Why would you exclude a broken SHA256 scenario? It's a perfectly valid reason to have a backup hashing algo in case the first one breaks. I'm assuming that if SHA256 gets broken, any backup variation of it automatically is also broken. The algorithm might need to change anyway, but it would break all ASICs. Then it should not be a variation, but a completely different hashing function. That probably doesn't come free. Since it is impossible to know in advance just how SHA256 will be broken (if it ever is), it is also probably not worth any cost to try to add a complete alternative to it, since it could just as well also be vulnerable. |
|
|
|
|
Show Posts
