I used this time to move my standing buy orders WAY down. If we spike up a dollar after this calm, I have other coins and I win. If we spike down a dollar, I want more coins because I don't believe it will stay down for long.
Don't take this as advice. I'm working with like $120.
Yep, thinking along the same lines. The way the +dollar crash / spikes have been happening, you could wake up to find your Buy orders filled with a 25% price increase. I should have started a betting pool on how low the next knife would go. The questions now are probably " When will it move back to the $6.20 range?" and "Will it overshoot on the way?". |
|
|
|
Why do you think Satoshi didn't choose to keep the entire current state present?
I don't understand the question. I didn't either, at first, but I think what he's trying to get at is: Why didn't Satoshi do this from the beginning? And before you say anything, keep in mind that more often than not, Satoshi had an explicit reason for what he did. This is a valid question that all changes to Bitcoin should have thoroughly answered before they move forward. Bingo. And at this point, that is my only remaining big objection. It could be that he just didn't think of it, but it seems more likely that he did think of it and rejected it for some reason unknown to us. I still think that the logistics and hashing of the tree will be troublesome, but not unsolvable. And I may be wrong about this and the exact implementation offered will be good enough as-is. You would still need to fetch the block body for any block involved in a transaction that you care about.
Only the transactions used as inputs, the merkle tree and MTUT verification hashes. Unless you want to validate those transactions too, in that case you need the full blockchain. It shouldn't be needed if implemented correctly. I see your objection that you would then have to trust a third party to do the search to make sure that the transaction hasn't already been spent, but that really isn't a big deal.
It is a big deal. Unless new users are encoruaged to download electrum before trying the official client. Let's change bitcoin.org, bitcoin.it, weusecoins, wikipedia, etc, to point to electrum instead of the full client. I mean, the idea of thin clients is great, but such functionality is not built in the official client because it somewhat defeats the purpose of decentralization (and it's a different protocol/API, etc). This was for the case of a light client using a different modification of the system, not for MTUT. The modifications to the protocol to allow searches by address or transaction ID would be pretty simple, and would support light clients in almost all situations. Or, you could do it with the bitcoin protocol without changes. With bitcoin + electrum you could search electrum for the blocks containing the transactions you need, then use bitcoin (the protocol) to fetch and verify them. |
|
|
|
Doh. That sucks for him and his family. A "legal scholar" said: "Utah laws are silent on replica firearms and antique firearms," he notes. If the cannon that killed Ostberg was designed to fire a .50-caliber round, Turley asks, should it be treated as a firearm and should it come with warnings and a safety lock, he asks. Muzzle loaders are exempt from pretty much every firearms law at every level. Can't be much of a legal scholar if you don't know that. |
|
|
|
|
I marked "Other" in the poll.
I still use cdhowie's mining proxy, with a bunch of modifications, for central management, and linuxcoin with custom scripts for on-box management.
My local scripts are smart enough to restart stuck miners, and my central tool is capable of doing remote reboots on boxes that are totally hung.
|
|
|
|
So one way to vote no is to join the Eclipse pool? Unfortunately for me I am not brave enough to cope with their color scheme  "No" votes are completely useless. They are exactly the same as not voting at all. Again, this is not a vote. Sorry I must have missed something? The acceptance of p2sh comes down to 51% of the hash power running the new software? So if you are not solo mining then one way to have a 'vote', so to speak, would be to lend your hash power to a pool that represents your position i.e. running to new software or not. I have read several of these threads so maybe I have things mixed up Exactly right. What matters is whether or not /P2SH/ ends up in the blockchain. If you aren't directly hashing your own blocks and submitting them to the network (a solo miner), then you don't need the software at all, you just need to pick a pool that matches your preference. At least one well known pool has committed to each side, and several others have stated their preferences, but haven't implemented it yet. |
|
|
|
|
You can either work for people that already "get" bitcoin, or you can try to convince them.
Keep in mind that people have gone to prison for using alternate payment systems (mostly to evade taxes), so don't expect this to be easy. But all cases like that, so far as I'm aware, have been about evading taxes on wages, or by kooks thinking that they can establish allodial titles by dubious means, so a straight contract for BTC should be just as legal as one for comic books (or whatever), so long as taxes are paid properly.
|
|
|
|
This is exactly my problem...
They wont get fired if they delay the schedule by a few months or even a year.
Think October. No, not The Hunt for Red October. Last October. The devs have been at it since last October! then the wiki is misleading... It states that P2SH was created on Jan 3 ( I assumed it wasnt tested on testcoin before that time) I am not talking about months of development - i am talking about months of practical testing on testnet Yes, this was tested on the test network, after being tested on a virtual test network. root@inana:/usr/src/bitcoin-0.5.2-linux# grep -i subsidy `find -type f`
./src/src/main.cpp: int64 nSubsidy = 50 * COIN;
./src/src/main.cpp: // Subsidy is cut in half every 4 years
./src/src/main.cpp: nSubsidy >>= (nHeight / 210000);
./src/src/main.cpp: return nSubsidy + nFees;
root@inana:/usr/src/bitcoin-0.5.2-linux# grep -i P2SH `find -type f`
root@inana:/usr/src/bitcoin-0.5.2-linux#
0.5.2 does not include P2SH. To register a vote for P2SH, you have to go out of your way to do it by building from git. The presence of /P2SH/ in a coinbase can be taken as pretty strong evidence of two things. First, that a mining node with a decent amount of hashing power is capable of mining blocks with transactions that include P2SH, and second that someone actually intended to make their support public. For a few days, it was possible to grab the master branch and compile it with P2SH support without knowing, but that was a while ago, and like you said: who the hell installs their client from the latest github source?
The answer is "almost no one", and that is the whole point. If enough of the hashing power goes out of their way to include /P2SH/ in their coinbases, we are ready to move forward. Otherwise, there is no point working on the other stuff that will be needed before it can actually be used. And I'm going to merge two replies that popped up while I was typing this. Edit:
consider the following scenario:
2 non techie bitcoin users who dont read the forums. user A has 0.6.0 user B has 0.5.2
User A buys something from user B
User A: "i have sent you the money" (using p2sh) This step is not possible without a bunch of manual work. User B would have had to provide a P2SH address, and those don't even officially exist yet. Seriously, don't hold this against me but the fact that I need to explain all of this to you means that we probably shouldn't have wasted time on this conversation.
Please, please, please go read up on this before you ask anything else. This is a complicated topic, and there is no shame in not knowing how it all works, but your posts strongly suggest that you also haven't bothered to do even minimal research on the subject. Your question about the potential scam is pretty troubling, since user B is the scammer, so it doesn't matter what version of the client he is using, and user A will see the payment as plain as day. |
|
|
|
|
Ha! I guess that's what you get for bumping the thread to tell people that guessing has closed.
|
|
|
|
|
Also, I'd be surprised if there aren't already a half dozen people running scripts to find and sweep transactions signed by weak keys.
|
|
|
|
The devs want multiple signatures enabled yesterday, even should the resulting code be less elegant. This is exactly my problem... They wont get fired if they delay the schedule by a few months or even a year. This change is supposed to stay in the system for as long as it exists. Not using a possibly better solution that will need to work for decades because you didn't want to delay the schedule by a few months sounds silly to me. Another concern i have is compatibility. some people will be using an older client. If you asked me, first i would have released a client that can properly validate P2SH but will refuse to create such transactions, and only a few months later release a client that can actually create such transactions. This way the clients will have to be 2 versions and about 4-6 months behind the current version to be affected in any way by this change. Seriously man, go do some reading. The master branch on github can process P2SH transactions today, but doesn't create them. There will need to be huge changes in the wallet and UI before any P2SH transactions can actually be created except through custom tools and/or hand crafting. |
|
|
|
My question is due to us getting bombarded every 2 days now with CME's coming from the sun, the next one scheduled to hit earth tomorrow is that something I could be using for promotional stuff?
You would just make a fool of yourself. Most computer cases are actual faraday cages, if properly grounded (and within there are plenty more, hdds for instance). Not to protect against external radiation but to shield you nearby licensed radio operations against EM emission from within the case. Now "cosmic bombardment". Those very fast protons hit our atmosphere (causing nice looking aurorae) and decay mostly to muons at ground level. Bad news, there is no reasonable way to avoid them. Even if you put your safe deep beyond a mountain, they will get ya. Fixed that for ya. Not even the crazies think that RFI from a computer is harmful to humans any more, but the FCC takes a dim view of anything that interferes with licensed radio systems. They'd fine the sun for harmful interference if they could. And my understanding was that muons were just a tiny bit harder to stop than beta rays, since they have the same electrical interactions, just a (lot) more mass. The real problem is X-rays (or gamma rays, or cosmic rays, depending on which decade your physics textbook was written in), since they can penetrate and ionize. But that is mostly a problem for solid state storage, which brings us back to deepceleron's point, that the real protection needed is on the power line. Hmm. I wonder if my coil winder is big enough to make a ferroresonant transformer big enough for the whole house. |
|
|
|
Even though i am not familiar with the code. Me and many others here are familiar with the software development cycle and how log each step in that cycle usually takes.
It seems to me that things were rushed regarding the p2sh. Statements "p2sh should be implemented ASASP" are all over the forum.
From my experience so far - beta testing and debugging, after everything was implemented takes at least a couple of months. Introducing major changes to the live client a month after the idea occurred seems too fast to me.
You need to go read the threads, the IRC logs and the mailing list archives again if you think that this popped up on 30 days notice. The magic word for today is October. |
|
|
|
I think it's a non-issue. Imagine if they decided they want to take out everybody seeding illegal torrents - something they are already interested in doing today. Look how successful they've (not) been. And that's for something that is undisputedly illegal. Bitcoin mining is not.
I think Bitcoin has the potential to be more disruptive than bittorrent. Also, Bitcoin is currently much more centralized. I think it could survive a "coordinated attack", but it will set it back for a long time. I'd prefer the proactive approach so it's simply no longer vulnerable. Agreed. BitTorrent hurts an the entertainment industry and the entertainment industry attacks it. BitCoin could hurt world financial markets and their respective governments if not done with great care. I would tend to believe that the pressure brought to bare from those two entities could be a little more effective than the entertainment industries. Bittorrent itself isn't centralized, or even centralizable. The concepts just don't fit together. What is centralized is the sharing of torrent files. The world has exactly one good public torrent site, a bunch of good(semi-)private sites, and a billion spammy/scammy/crappy sites. That one good public site has stood up to the entire entertainment racket for a long time, armed with nothing but chutzpah. Bitcoin itself is similarly decentralized by nature, but has a few high profile central services. The exchanges, for example, are vulnerable to attack, but the bitcoin network wouldn't even blink. |
|
|
|
|
The stock client doesn't accept human input for private keys, it generates them at random. To get a custom key in, you need to manipulate the wallet database. If you are clever enough to do that, you are clever enough to accept your own losses.
|
|
|
|
Why in the world would you redeem your Private Key to your wallet on MTGOX?
I believe that feature was to redeem the 'Physical Coin' private keys, not your wallets. But hey, the same rule applies if it can be done; it will be done.
Assuming that the key in question is for a transaction with at least 6 confirmations, it should happen pretty much instantly, or most with a single block delay. |
|
|
|
Does anyone else have difficulty undervolting thier 6870? MSI just kinda... Ignores the fact that i want to change the slider value
I gave up. My 6870s just run at stock speed, and I don't care any more. |
|
|
|
|
Have you tried Linuxcoin?
|
|
|
|
|
I used this time to move my standing buy orders WAY down. If we spike up a dollar after this calm, I have other coins and I win. If we spike down a dollar, I want more coins because I don't believe it will stay down for long.
Don't take this as advice. I'm working with like $120.
|
|
|
|
Because it is NOT a feature that can be toggled on and off. We're talking of protocol-level changes.
Why does trust in the core devs seem to have evaporated out of a sudden?
I'm hearing newbie members with a dozen or so posts raise the BIP16/17 issue... that's straight laughable.
1) people who are new on the forum are not necessarily new to bitcoin 2) there were some serious allegations against Luke who is one of the developers (using his pool for attacks, generating invalid blocks probably due to his modified client) I'm not a big fan of Luke's attitude or the way he has handled himself during the BIP16/17 dispute, but I do trust that he is absolutely committed, in his own way, to the health of the bitcoin system. There are no allegations that he's used his pool to attack various merged mining chains, just facts. He usually shows up in the threads in person to take credit for crushing them. But he only does this to systems that he considers scammy. So far, I agree with him, and I even bumped his pool up in my failover priority list because I support his efforts in this area. However, I did disable his pool entirely in my system until the BIP16/17 thing is resolved, because I prefer P2SH over CHV. Once that is resolved one way or the other, I intend to return. His pool mines non-standard transactions, but not invalid ones. The standard client will refuse to process (create, process or mine) transactions that don't fit the standard templates, and for very good reason, but that doesn't make other transactions invalid. If they were really invalid, the rest of the network would have rejected those blocks instead of building on them. People that want or need non-standard transactions have to take extra effort to get their transactions to his pool, and when they do that, they have to know that they are doing it without the safety net of the standard transaction checks. Also, not every forum noob is a bitcoin noob, but I'd bet $100 on each and every one of them, and I'd be a millionaire in a hurry. |
|
|
|
Double that, since the standard hashing that we do is highly optimized in ways that aren't useful for hashing a tree. But something that takes 6 minutes on a high end GPU is no longer a lightweight, or even middleweight client, since it will exclude 99.9% of all current nodes. And you are talking about something that every node must do.
By the time we have a 10 TB blockchain (I repeat: 10 TERABYTES), I'm sure you'll need much less than 6 minutes. And again, that's an operation for the whole tree. A single change only needs approx 11 hashes (in my 10 year example). I still think you are underestimating the number of hashes that will need to be done, and how often. This isn't a threat to the network, this is a threat to one node. Without the whole block chain, you can't add up the difficulty sum by tracing it all the way back to the genesis block.
You can, just the block headers is what you need (40 mb for 10 years of headers). Satoshi already thought of that. Read his paper again if unsure. Good point. But with that in mind, does any light client need more than just the headers and the latest X blocks, where X is the reorg depth you are worried about? You would still need to fetch the block body for any block involved in a transaction that you care about. I see your objection that you would then have to trust a third party to do the search to make sure that the transaction hasn't already been spent, but that really isn't a big deal. Why do you think Satoshi didn't choose to keep the entire current state present? With your system, not even the most paranoid users would ever need to keep more than a few hundred blocks on hand. |
|
|
|
|
Show Posts
