I don't think this seller is reckless, but I do believe they have massive volume and only temporary sucking up the buyers over $2 while they can.
Exactly but in order to do that the oscillation may not be damped. Because if it is the buyers above 2 might not show up. Its the same game all over, curious why it still works. I've yet to hear a cogent and descriptive definition of 'game over', and in fact I don't think I've ever heard anyone really tackle that. A handful of folks fiddling around with Bitcoin on packet radio or some such could have 'a game' and probably kind of an interesting one. I'm guessing that Chodpaba was right and we are in a phase where BTC changes hands from the category of people who would tend to be early adopters of something like Bitcoin to a different, unspecified, category. 'bag holders'? Possibly. Time will tell. "Game over": A phrase used to describe the Bitcoin price changes past December 21, 2012. |
|
|
|
|
We've spiked above $2.1 again. Is this just one huge buy, or a sign of a reversal?
|
|
|
|
that was interesting -- network hash rate just increased 3 fold with last difficulty change. Is someone implementing this now?
I doubt it. Solidcoin prices have also increased 3-fold, so that may have been a factor. It went back down in the morning... It was 0.14 last night on allchains and then this morning 0.04. Very strange. My data says it's 0.18 right now... |
|
|
|
that was interesting -- network hash rate just increased 3 fold with last difficulty change. Is someone implementing this now?
I doubt it. Solidcoin prices have also increased 3-fold, so that may have been a factor. |
|
|
|
Hai Guyz, I made a chart to esplain everything
The first few dips looked like smilies - the later ones look like shark's teeth. That does indeed explain everything, thank you. This also explains everything.  (price smoothed 400 days because of noise). |
|
|
|
Hi again,
I don't know if this is a known fact, but pressing Ctrl+C on a bitcoind.exe running inside a console on win32 throws an exception:
C:\Programmi\Bitcoin\daemon>bitcoind
terminate called after throwing an instance of 'DbException'
what(): DbEnv::close: Invalid argument
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Best regards.
spiccioli
Ctrl+C is a common interupt. I assume bitcoind tries to exit without doing cleanup. |
|
|
|
Context: If I can buy a ring of bitcoin, and propose to my girlfriend with it, then bitcoin is like gold. If I can't, then your argument fails.
I wonder if I can embed a private key inside a ring. Then it really would be a ring of bitcoin. The ring can be the private key  . Just arrange materials in slots. For example, one can divide the ring into 12 slots, 3 checksum slots, and 1 redundency slot. Each slot can contain: - Hex 0: nothing (just round)
- Hex 1: Purple gem
- Hex 2: Blue gem
- Hex 3: Green gem
- Hex 4: Yellow gem
- Hex 5: Orange gem
- Hex 6: Red gem
- Hex 7: Gold bar
- Hex 8: Silver bar
- Hex 9: Wooden piece
- Hex A: Graphite piece
- Hex B: Diamond piece
- Hex C: Rock piece
- Hex D: Inscription "vires en numeris"
- Hex E: Aluminum plating
- Hex F: thin tube of ring material
With the exception of the redundency slot, which is a 4x12 box of elevated/non-elevated ring material. Then SHA256 the resulting data if the checksum computes. Otherwise, use the redundency slot because the ring must be damaged. On a more serious note, it would be cool if everyday objects could be made to include bitcoin private keys/addresses. Think of the applications of that! "Pay 0.1 BTC to address to play slots". Or, "Buy this table for 500 BTC, and get back a private key with 50 untouched BTC!". Etc. |
|
|
|
Water cooling won't reduce the thermal load. Water cooling makes the heat transfer more efficient reducing noise and required airflow but energy in = energy out.
If the rig draws 1000W at the wall it will dump 1000W into air.
Why does it need to be in air? My dryer produces 800W of heat, but it all goes outside. It could just as easily be fanned underground as well. |
|
|
|
The default client only sends transactions with at least one confirmation, so this is an entire non-issue.
The default client only originates transactions where the inputs have at least one confirmation. It relays all transactions that follow the rules. This is what I meant. You do not need to worry about a transaction until it actually becomes included in a block. lol, didn't really want to post but this is to funny to resist... q: how would you relay a sole transaction when it's part of a block ? My statement is simply that you do not need to relay a transaction not involving you. This was in response to Steve's point that you need to know the "future ledger" in case of it concerning you later, and my responce was that you can worry about it once it is in a block. The default client only sends transactions with at least one confirmation, so this is an entire non-issue.
The default client only originates transactions where the inputs have at least one confirmation. It relays all transactions that follow the rules. This is what I meant. You do not need to worry about a transaction until it actually becomes included in a block. lol, didn't really want to post but this is to funny to resist... q: how would you relay a sole transaction when it's part of a block ? No, I get what he's saying now. If you're looking to use the output from a transaction before that transaction is included in a block, you can't do that with the mainline client; therefore, the mainline client has no incentive to relay non-confirmed transactions. But if you're using the mainline client already, you're relaying. You can modify it to not relay, but you could just as easily modify it to originate transactions with unconfirmed outputs. No, I'm saying there is no need to know the output until it is included in a block. |
|
|
|
The default client only sends transactions with at least one confirmation, so this is an entire non-issue.
The default client only originates transactions where the inputs have at least one confirmation. It relays all transactions that follow the rules. This is what I meant. You do not need to worry about a transaction until it acually becomes included in a block. |
|
|
|
No, if Bitcoin were to be widely used most non-miner nodes would have jobs. There is no incentive to relay transactions that don't concern them at all.
Incorrect. You never know what transactions might precede a transaction that sends bitcoins to an address you control. Therefore, you are potentially interested in every transaction and have a need to stay in sync with the rest of the network. If you control address C and there is a sequence of two transactions, A->B then B->C and you don't relay the first one, you increase the chance that the network settles on a transaction that conflicts with A->B and you'll miss out on B->C (or worse, you'll think it's a valid transaction when the rest of the network has already rejected it). The default client only sends transactions with at least one confirmation, so this is an entire non-issue. |
|
|
|
I think he's trying to figure out if the market goes up or down. The market's fate likely resides in the hands of the guy with the million. If he wants to go up it most likely will, likewise in the other direction.
So he can somehow buy $1M at below market rates? I think this is what he'll choose then and we've somehow established that huge demand pushes prices down. This is completely possible. It's the entire concept behind dark pools: place a giagantic order that won't arouse suspicion. Then sell a large quanity of coins you slowly bought, and build an ask wall. As the price tumbles, you earn bitcoins from $. |
|
|
|
That means not only receiving transactions, but also relaying them (because, you never know, you might be the first and only one to receive a given transaction…if you don't relay it, you risk getting out of sync and thinking later transactions that you see are valid when the rest of the network does not agree with you).
(emphasis mine) That part isn't valid because if the blockchain never accepts the transaction, it never existed. Your client wouldn't think it existed at all because it follows the blockchain. To clarify, a client can simple delete the transaction and nothing would be out-of sync. If the transaction does get included, your blockchain will have it. Nodes want to be in sync with the rest of the network, even for transactions that have not yet made it into a block. The reason is that with such knowledge, you can make a risk assessment regarding whether a given transaction is likely to make it into the block chain. Again, I assert that there is plenty of incentive to relay transactions. I might be being a little unclear (or you are  ), but what I meant is that the average node isn't a merchant: they have no need to relay transactions that don't involve them. No risk assessment needs to be made, as even if you do relay a transaction this isn't a guarentee it exists. sorry to interrupt, i just read your reply 4 times to understand something dree12... ...average node isn't a merchant... = wrong assumption, 50% of non miner nodes are "merchants" at any given time. Me accepting coins for a sale or service for example No, if Bitcoin were to be widely used most non-miner nodes would have jobs. There is no incentive to relay transactions that don't concern them at all. My point is that relaying a transaction is useless if it doesn't concern you. If those txs get included in the chain, so be it - you haven't lost anything. Otherwise, you delayed a transaction not belonging to you, making yours get comfirmed faster. |
|
|
|
That means not only receiving transactions, but also relaying them (because, you never know, you might be the first and only one to receive a given transaction…if you don't relay it, you risk getting out of sync and thinking later transactions that you see are valid when the rest of the network does not agree with you).
(emphasis mine) That part isn't valid because if the blockchain never accepts the transaction, it never existed. Your client wouldn't think it existed at all because it follows the blockchain. To clarify, a client can simple delete the transaction and nothing would be out-of sync. If the transaction does get included, your blockchain will have it. Nodes want to be in sync with the rest of the network, even for transactions that have not yet made it into a block. The reason is that with such knowledge, you can make a risk assessment regarding whether a given transaction is likely to make it into the block chain. Again, I assert that there is plenty of incentive to relay transactions. I might be being a little unclear (or you are ), but what I meant is that the average node isn't a merchant: they have no need to relay transactions that don't involve them. No risk assessment needs to be made, as even if you do relay a transaction this isn't a guarentee it exists. |
|
|
|
I don't see the problem with incentives for relaying transactions. Every non mining node has a very strong incentive to relay transactions. When you are the recipient of bitcoins, you need to make an assessment of whether that transaction is marketable to the rest of the network. To do that effectively, you need to be as in sync with the rest of the network as possible. That means not only receiving transactions, but also relaying them (because, you never know, you might be the first and only one to receive a given transaction…if you don't relay it, you risk getting out of sync and thinking later transactions that you see are valid when the rest of the network does not agree with you).
(emphasis mine) That part isn't valid because if the blockchain never accepts the transaction, it never existed. Your client wouldn't think it existed at all because it follows the blockchain. To clarify, a client can simple delete the transaction and nothing would be out-of sync. If the transaction does get included, your blockchain will have it. |
|
|
|
I'm willing to bet the next emergency release will have Coinhunter with the ability to "Manually" adjust the difficulty.
Believe it or not, I'm willing to counter-bet. How about these terms: An "emergency release" is defined as a release that meets ALL these conditions: - Coinhunter indicates that all clients must upgrade to the release in a forum post somewhere
- An alert is posted on solidcoin.info if it still exists. In the event solidcoin.info no longer exists, whatever website is promoted as the Solidcoin website by Coinhunter will replace solidcoin.info. In the event Coinhunter does not promote any website for solidcoin, no "emergency release" can exist.
- The release occurs before 2011-01-01 00:00:00 UTC
If the first "emergency release" after 2011-11-20 00:00:00 UTC adds explicitly in the source code code which allows CoinHunter or other control nodes to manually adjust difficulty, assuming difficulty still exists, you have won the bet. Otherwise, I have won. If SolidCoin is changed drastically and difficulty or a derivative of its concept no longer exists, the bet is void. |
|
|
|
Remember that this 14% won't be coordinated, so you won't come ahead at all... there needs to be 14% more miners doing one side than the other. This is an useless exploit IMO - even worse than powerblock-only mining.
Well... if everyone does it pretty much everyone wins in terms of getting more for less. Alternatively if you represent 50% of the network hash rate, it allows you to mine more than double the amount of coin. With the difficultly algorithm the way it is (as was explained on BTC-e earlier), for every amount you decrease it the increased return in coin is exponential. All it takes is one of the large scale miners currently doing tens or hundreds of gh/s of BTC to use the script as described and the whole SC2 network will be hijacked. I was writing the script earlier today but got snagged in some python bugginess; it shouldn't be too hard to implement though. Then all people need to do is mine together using the same script. To use the script makes more sense in terms of profit/watt, so it seems obvious that people would coordinate with it. As soon as someone does to a large extent it's likely others will follow. How do you prevent half the people mining odd difficulty adjustments, and half mining even ones? People are stubborn. This won't ever work. Why don't people coodinate to elect one party this election and the other the next? This will evidently be good for the people. Same thing with pressuring companies to improve: if 90% of people switched away from Windows, the next version of Windows is guarenteed to be awesome. |
|
|
|
SC2 has a special difficulty algorithm that allows for vast decreases in difficulty per 360 blocks (~200%) but only small increases (~14%). It seems that this could be exploited by using a script that does the following:
1.) Mines SC2 when ((number of blocks / 360) % 2 == 0), that is, every other difficulty difficulty adjustment period.
2.) Mines BTC when ((number of blocks / 360) % 2 != 0). This would allow you to use your cards for BTC in the meantime.
If a large number of people use such a script, for example 90% of the miners, the difficulty will quickly drop to what it would be if only 10% of the network were mining. This would maximize return per watt for people mining SC2, yielding bitcoin when they aren't mining SC2.
The difficulty won't drop, because miners with less than 1M SC can't mine trusted blocks. So it hasn't any effect on the actual blocks/time. You can decide to not mine SC, and the difficulty will drop a little bit. He's not talking about mining every other block, hes suggesting mining every other difficulty adjustment period. So you mine the user blocks for one 360 block period then you go away for the next 360 block period. If over 14% of the mining power does this you will come out ahead (on a per cpu cycle spent mining solidcoin) of where you would be if you mined solidcoin full time. Remember that this 14% won't be coordinated, so you won't come ahead at all... there needs to be 14% more miners doing one side than the other. This is an useless exploit IMO - even worse than powerblock-only mining. |
|
|
|
Update.
*update*
Looks like these charts are changing again. Is today one of the most active days in your record? |
|
|
|
And with that 20000 coin sale that happened just now, volume records have been broken.
Has anyone noticed that we've set a new record for daily Bitcoin trading volume on Mt Gox? Dunno what the significance of that is, but cool none the less.
A couple hours before, yes. |
|
|
|
|
Show Posts
