Transaction is finally on my Multibit client but it's taking forever to fucking confirm! It's up to 10 peers right now. Lol.
Since most peers are droping the tx the best thing the sender can do is delete the original tx and then create a new one with proper fee, and no dust outputs. It should propogate the network very rapidly (as only nodes which kept the original will block it) and will be included in a block by a miner quickly. This transaction in theory could not confirm in decades if no miner either is relayed the tx or chooses to not drop it from the memory pool. |
|
|
|
Open source does not mean that it is accessible to ordinary users. Most people don't know C++ and can't understand the code. Nobody is saying your average non-developer grandmother is going to scrutinize the code. However even among experienced developers the population is large enough that the probability of nobody noticing a change in the source code is remote. In this case the subsidy per block is very transparent and simple. int64_t GetBlockValue(int nHeight, int64_t nFees)
{
int64_t nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
nSubsidy >>= (nHeight / Params().SubsidyHalvingInterval());
return nSubsidy + nFees;
}
Tools like git allow you to quickly summarize line by line changes between versions. I know I at least look over the diffs between versions. For entities who's financial fortunes depend on Bitcoin there is huge vested interest to ensure the codebase doesn't contain malicious code. Lets imagine nobody at the second market (operator of Bitcoin Trust) has any knowledge of C++. They have money, and money can buy the services of an expert. Do you think it might be in their economic self interest to use a tiny tiny tiny % of their gross revenue to have an expert or two review the git diffs to ensure the network they depend heavily on for the financial prosperity isn't maliciously modified? The same scenario would apply to exchanges, service providers, and even merchants who someday may be highly dependent on Bitcoin. Lets say someday Overstock is doing a billion dollars a year in Bitcoin sales. Do you think it might be prudent for the the board to retain some bitcoin developers on the payroll to ensure the risks associated with the bitcoin network are mitigated? Shareholders might even say that it was their fiduciary duty to ensure they take steps to protect the company's bottom line against a known risk factor. Then there are countless hackers, hobbyists, and academic developers. Finding a hidden poison pill would be massive. None of them will notice it? That is the power of open source. It doesn't take every human on the planet looking at it. Even 0.1% of the population is many magnitudes more eyeballs than what ends up seeing closed source software. |
|
|
|
On a long enough timeline I think "fraudulent" miners are all but an inevitability. I could see an entity with say 20% of the network willing to accept out of band double spends for a hefty fee (either flat rate say $10 per tx, or a % of the tx amount). Do you not think large retailers might mitigate that risk by becoming miners themselves? If Bitcoin succeeds, I would expect many entities to be willing to devote some resources to mining, to make it harder for others to control a sizeable fraction of the network. With that goal, they don't need to make a profit, although any mining income will help defray the costs. The issue isn't that all miners would be fraudulent but rather a small % would. I certainly do think merchants may organize to better control tx processing but that doesn't eliminate the risk of a fraudulent miner. Depending on the risk profile and the profit margin 0-confirm may simply not be viable for all merchants in all situations because the chance of a fraudulent miner intentionally including the double spend in the next block can never be guaranteed to be 0% and merchants running a transaction processing pool can't make that 0% either. |
|
|
|
|
Yeah that is it. (I guess it is a small "sea" of nodes, maybe a pond of nodes).
You got a link to the original?
|
|
|
|
The BitSimple site looks good. In the terms and conditions it says United States only. Is there any chance at all it could be opened up to the users in the U.K.
We are lacking a site over here that offers quick conversion for buying or selling over here.
Yes. International support will be announced later this month and UK will be one of the initial supported countries. Thank you for your interest. |
|
|
|
|
I remember at one time someone had created a photo/background which had bitcoin logo and behind it there was a "sea" of stylized dots representing nodes and the connections between them. I have later seen it used in articles and blog posts but I can't seem to find it now.
Anyone know what I am talking about or do I just sound like a crazy person.
Mods if this should be moved go ahead, I wasn't really sure where "I lost an image someone else made related to Bitcoin" goes.
|
|
|
|
Nice idea for a prototype. What is your plan for the full scale version? I mean what size, shape, ASIC configuration are you targeting. Using custom 3D printing is a good idea to reduce excess fluid usage. What materials are you considering. I was thinking of that but my concern would be an interaction between the 3D printing composite and the working fluid. Too bad there are no 3D printers which can "print" stainless steel. As an alternative I was thinking about maybe taking the 3D design and slicing it into layers and then cutting each layer with a CNC. The layers could then be stacked inside the chassis. On edit: I see you are looking to cool a MB and GPU combo not ASICs. On the pressure issue. You may want to weigh your prototype with a high accuracy scale over time. Under pressure Novec escapes most seals pretty well so you likely are encountering fluid loss. Weighing the entire system over time is a good way to measure that rate of loss. Improving the relative performance of the condensor and keeping the pressure differential as close to 0 as possible will reduce fluid loss to a minimal amount. It may not be as much of an issue with your small prototype and low energy load but with a larger heat load and larger seal surface area unless you design it to be hermetic the fluid loss rate might be unacceptable when under pressure. |
|
|
|
Some high end defense components use a third concept called spray cooling where a nozzle sprays fluid directly onto the chip.
Just popping in to say that you typically use nozzle sprays where space/weight is an issue. You can significantly reduce the working fluid required. Agreed. An example would be to cool the imaging system on a drone. Every pound counts so the cost, complexity, and maintenance of a spray cooling system is worth it to cut a couple pounds on the final weight. For hobbyist coolers thinking beyond bath cooling is getting the cart before the horse. Bath cooling has enough challenges as it is. Yes alternatives can support higher energy densities but you lose the "simplicity" of the passive nature of bath cooling. Throwing in flow cooling (pumping fluid past the component) or spray cooling (directing jet of fluid at the component surface) is just layering complexity on top of complexity. |
|
|
|
From my experience getting people setup with all manner of equipment, 8 pin ATX = roughly 8 pin PCI-E from any reputable brand. With unbranded stuff its a lottery what you get anyway, but something like Corsair would work fine.
and don't buy an off brand PSU. A sold rig (or server or workstation) starts with solid reliable power. Power issues (beyond the PSU just dies or explodes) can cause all kinds of weird instability issues. Files getting corrupted on disk? It could be a bad drive or it could be bad power. Keep getting driver crashes? It could be bad power. Due a memory check and it reports bad memory? It could also be bad power. Weird performance issues, hard lockups under high load or CPU/GPU throttling back? It could be a defective component or bad power. Since bad power can show up as almost any computer problem starting with cheap power supply is just setting yourself up for failure. Plus quality name brand PSU (corsair, enermax, xfx, and my personal favorite SeaSonic) generally are built better, have "beefier" caps, more overhead, and carry long warranties. SeaSonic has 5 year warranties, pretty much no questions asked. The same SeaSonic PSU has outlived three or four rebuilt workstations. Spend the coins and start with solid reliable power. The PSU will still be useful long after you stop mining. |
|
|
|
Seriously guys? Please start reading posts! Someone helped immensely by posting their horrid customer service experience emails right above your posts.
What made you think that using the service was a good idea after that? Your money is your power, please be a little more cautious with it. I wish you all a smooth and speedy recovery, I would love to see some redemption for this company but for now it is clearly looking like a scam.
I honestly can't believe it. People wonder why scammers are attacted to bitcoin. You have someone reporting a non payment and then other users line up to throw their money at the scammer as fast as possible. If they had used BitSimple ( https://BitSimple.com ) they would have gotten paid the same day, everyday. The rate is about 1% lower but then again when you have no intention on paying you can offer the "best" possible rate. |
|
|
|
Yeah don't use molex!
Some time ago I had some HEX16A miners from technobit, they use about 80 watt each and are powered by a molex connector. My PSU only had one cable with molex connectors (like most modern PSU's do these days) and when I had one miner on the cable it already got quite hot. When I had 2 on the same cable it became too hot to hold for over 30 seconds. When I added a 3rd one the cable became too hot to even touch.
To OP:
I understand why you're asking this, but you might want to consider buying an extra PSU. Usually PSU's are most efficient if they're being used for about 50-75% of their capacity. And besides that, it's probably quite some money you've spent on GPU's, why would you risk losing them (or the PSU)?
Maybe it's just my philosophy, but I would never do "tricks" with PSU's to save a few dollars, I would go for the safer solution to be sure it will run like it should.
Molex have a 150 watt capacity, just make sure you don't cross that. Well it is 11A so that is 132W on the 12V rail but most molex connectors will die under a load like that. They are routinely used for much lower wattage especially in the last decade when MB and GPU got their own dedicated high current connectors so the Molex connectors were left to power fans and CD Roms. They don't get much love in the over engineering department. Plus is it a pretty old connector design without any retention clip so it is pretty easy for them to work themselves slightly loose. Even a barely loose connector can increase resistance by a magnitude. High current + increased resistance + cheapest possible part they could source + bad luck = fire. If the OP setup isn't using the 8 pin CPU connector and OP can find a suitable adapter I would use that. The 8 pin CPU connector is designed to provide up to 250W to the motherboard. |
|
|
|
|
To spend that 1 satoshi would require a fee of ~5430 satoshis. Sound like a great deal now? It is very likely the transaction will never confirm (because no miner wants to waste space in a block for that monster tx) and thus eventually it will be dropped from the memory pool.
|
|
|
|
|
If you mean can a pool miner keep the block for himself? No the hash found solves on a specific exact block and part of that block is the reward to the pool. The hash the miner finds is useless for solving any other block.
|
|
|
|
It depends on the state. A Central Texas man who shot and killed a sheriff's deputy entering his home will not be charged with capital murder, attorneys said Thursday.
A local grand jury declined Wednesday to indict Henry Goedrich Magee for the Dec. 19 death of Burleson County Sgt. Adam Sowders, who was part of a group of investigators executing a search warrant for Magee's rural home.
Sowders and other officers entered the home about 90 miles northwest of Houston without knocking just before 6 a.m. Authorities were looking for guns and marijuana.
Magee's attorney, Dick DeGuerin, said his client thought he was being burglarized, reached for a gun and opened fire. http://www.charlotteobserver.com/2014/02/06/4668574/grand-jury-wont-indict-man-who.html#.UwMSBfldUomJuries often reflect the viewpoints of the population at large and my guess in Texas they are getting sick and tired of using no knock warranties to bust non violent offenders just so sheriff boys get to play soldier using military weapons, gear, and tactics. The jury was sending a message to judges and prosecutors. If you order a no knock warrant and get someone killed the blood is on your hands. |
|
|
|
This will likely never confirm. Who sent you this? If you don't mind, please share this info. Smells fishy as the sender likely hopes it will get dropped after sometime.
Yeah it could be a good setup for a double spend. Attacker creates tx, feigns ignorance on why it won't confirm. After the deal is completed, miners eventually drop the tx from memory pool and attacker double spends. No real "race" because the legit tx was kneecapped at the starting line. |
|
|
|
Is there any place in the US where I can actually buy BTC above board? Or, is my only option to wrangle with the Com-block exchanges? Is you can make a bankwire, BitSimple ( https://BitSimple.com) can deliver your purchased bitcoins directly to your bitcoin address the same day. We don't hold customer bitcoins and we don't cancel transactions after the fact for "high risk". |
|
|
|
Since OP decided to cross post this everywhere here is my response from the other thread. OP don't do that again. It is annoying to find the same post in multiple sub forums. The other forum is a better location this isn't a development & technical discussion it is a request for support. Insufficient tx fees. The tx is low priority which means most nodes will require a tx fee to relay. The min fee for relaying on low priority tx is 0.1 mBTC per KB. The tx is 4KB (rounded up) so the min fee would be 0.4 mBTC. Miners running reference implementation see txs with fee below the min as free. It will be included whenever a miner has space for a free transaction. It could be the next block or it could be next week. It also has an output below the dust threshold which means most nodes and miners will simply drop this tx as invalid. Did you create this tx? It shouldn't be possible to create a tx like this using the reference client (or one which follows similar rules). If you send a tx without fees (and less than min for low priority tx is essentially zero) then you are relying on the generosity of miners to include it when they can. If you create a non-standard tx then all bets are off. It may never get relayed by anyone to any miner or one or more miners may simply drop it from the memory pool. In hindsight blockchain.info already said essentially the same thing Confirmation Warnings: Low priority. This transaction has a very small output and is none* (sic) standard. The transaction fee is less than recommended. * none standard should be non-standard. |
|
|
|
Insufficient tx fees. The tx is low priority which means most nodes will require a tx fee to relay. The min fee for relaying on low priority tx is 0.1 mBTC per KB. The tx is 4KB (rounded up) so the min fee would be 0.4 mBTC. Miners running reference implementation see txs with fee below the min as free. It will be included whenever a miner has space for a free transaction. It could be the next block or it could be next week. It also has an output below the dust threshold which means most nodes and miners will simply drop this tx as invalid. Did you create this tx? It shouldn't be possible to create a tx like this using the reference client (or one which follows similar rules). If you send a tx without fees (and less than min for low priority tx is essentially zero) then you are relying on the generosity of miners to include it when they can. If you create a non-standard tx then all bets are off. It may never get relayed by anyone to any miner or one or more miners may simply drop it from the memory pool. In hindsight blockchain.info already said essentially the same thing Confirmation Warnings: Low priority. This transaction has a very small output and is none* (sic) standard. The transaction fee is less than recommended. * none standard should be non-standard. |
|
|
|
Investing in Bitcoin early is no different from buying Apple shares in the 1990s! I see the point you are making but I would change this to something other than a stock. Stocks (or the company they represent ownership in) generate revenue and profit. A bitcoin doesn't generate revenue, it doesn't have dividends. While it may increase in value there is no underlying cashflow to fall back on if it doesn't. If you were to pick an asset Bitcoin is more like gold which has seen a tremendous rise in price relative to most currencies since those nations exited the gold standard. |
|
|
|
|
That certainly is an alternative solution. The tx id just needs to be a unique way to identify each transaction. It doesn't necessarily have to include the signature. It is possible that in the future there will be new tx types (extending the protocol) with different inputs but that isn't an impossible obstacle. Client support can be added before the switch in the same manner as it will be for any change.
It would however require clients to compute tx ids "one way" for existing tx in the blockchain (v1 txs) and a different way for future tx (v3 txs). I think that break with backwards compatibility is what the developers are looking to avoid.
Still if you wanted to compute the tx hash differently and there was consensus for such a breaking change there is a lot that can be done to improve the bitcoin transaction structure. The signature should not be in the input. The signature is of the tx, it should be outside the tx. The input should just deal with the input. You could also explicitly define the tx fee to avoid issues with implicit fees. You could use pubkey reconstruction to remove pubkeys from inputs. The S value could be computed deterministically from the tx hash to bypass the issue of poor PRNG implementation.
So if we are going to do a breaking change well there is a lot of cleanup which can be done. It would be possible to reduce the size of the average tx by 30% while keeping the same functionality and improving mutability and security. I don't think that is the route that we will go though as it would involve a breaking change.
|
|
|
|
|
Show Posts
