|
Many people think the arrival of ASIC will have impact on BTC price because the ASIC buyers will dump their BTC to recoup their investment on ASIC. First of all, I seriously doubt if this may happen because the buyers should be the most hardcore bitcoin believers, which would be more likely to hoard than dump.
However, just assume the worst case. For Avalon, they are selling 300units with $1300 each, ie. $390,000 totally. Assuming the miners want to fully recoup the $390,000, they need to dump about 28,000BTC and push the price down to about $13.61 (based on the current bid wall).
Please remember this is only the worst case. Since only 3600BTC is generated per day, the 28,000BTC will be generated in 8 days even Avalon takes over 100% of the network. Recently there are many 10,000BTC dumps and the market recovered very soon. Selling BTC3600/day for 8 days will be negligible. Not to mention some AISC owners may decide to hoard rather than dump.
|
|
|
|
No and it never will. A change like that would require literally 100% support of all users as it would be a hard incompatible fork.
No need to use tiny decimals though. 5 mBTC vs 0.005 BTC. 5 uBTC vs 0.000005 BTC. It is possible people will call these by slang or informal names. i.e. millies of mikes.
There is no need for a hard fork at all. The bitcoin protocol is already using integer (in satoshis) for transactions |
|
|
|
What are the reasons behind this rally? New investors for Bitpay? CES? New Megaupload?
The good news are not over yet. Ehh I mean the rumor. You know when to sell.  I think the raise from 13.4 to 13.8 in the last few days was triggered by insiders. A crash is expected if they want to take the short term profit. |
|
|
|
|
What are the reasons behind this rally? New investors for Bitpay? CES? New Megaupload?
|
|
|
|
You're way more knowledgeable than me, so I gotta ask. How do transaction fees reach the dedicated miners?
Each block is allowed a single transaction without an input, which the miner normally directs to a key they know, effectively their reward for finding that block. The size of that magic transaction is limited to not more than the sum of the fees (which are just the differences between the outputs and inputs of each individual transaction) plus the subsidy. Do you mean a miner may produce a valid block with total reward less than fee+basic_reward? Yes, and a few of them are in the block chain. From main.cpp, CBlock::ConnectBlock() : if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees))
return false;
Also in main.cpp, GetBlockValue() is a simple function: int64 static GetBlockValue(int nHeight, int64 nFees)
{
int64 nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
nSubsidy >>= (nHeight / 210000);
return nSubsidy + nFees;
}
So it's effectively destroying some bitcoins. |
|
|
|
I only tried double spend once. I sent a low priority tx without enough fee and got no confirmation after 24 hours. I resubmitted with higher fee and then got confirmed. However, you case is the opposite: trying to replace a higher fee tx with a low fee one.
Yup - probably a stupid idea also (when you panic - you panic) - am *so* grateful that I lucked upon being mined by a pool such as BTC Guild (my appreciation will never be forgotten - nor my understanding about how "sendrawtransaction" works). You have paid the highest tx fee in USD ( http://blockchain.info/charts/transaction-fees-usd?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address= ), and I am sure this record will be broken. It's better if the Satoshi client has a soft, adjustable upper limit for tx fee. The client will refuse to push if the fee is too high. A default of 0.5BTC is more than enough. In the not very remote future, when it hits $1400/BTC (100x of today's), you may donate 1 BTC back to them |
|
|
|
You're way more knowledgeable than me, so I gotta ask. How do transaction fees reach the dedicated miners?
Each block is allowed a single transaction without an input, which the miner normally directs to a key they know, effectively their reward for finding that block. The size of that magic transaction is limited to not more than the sum of the fees (which are just the differences between the outputs and inputs of each individual transaction) plus the subsidy. Do you mean a miner may produce a valid block with total reward less than fee+basic_reward? |
|
|
|
I won't let me send it (it has already seen it) - 2 confirmations now so too late for that attempt: Block #215936 (BTC Guild) - is there someone on Bitcointalk that is a contact for them? Does such double spend attempt ever work? As I know, most full nodes see transaction within seconds, and refuse any conflicting incoming transaction. It won't push or relay unless the code is modified. I only tried double spend once. I sent a low priority tx without enough fee and got no confirmation after 24 hours. I resubmitted with higher fee and then got confirmed. However, you case is the opposite: trying to replace a higher fee tx with a low fee one. |
|
|
|
LOL.
Did you see guys? And that's the way someone, very politely, could launder 101 tainted coins only paying 10 BTC for it.
Just kidding. You were very lucky P2pool or mistery miner didn't get it
AFAIK, mtred also pays tx fee to miners |
|
|
|
Wrong adress, wrong number, wrong whatever....
if you do that with bitcoin your only hope is that someone nice got it.
double check small transactions
triple check big transactions
The same for cash and most fungible property like gold (bitcoin is fungible property, too) |
|
|
|
My questions are:
1. If the miner was found and refused to return the money, would he/she be labelled as scammer? I would say no. 2. In this case, do those PPLNS users have the responsibility to return the extra earning? They can for the sake of good will, but they wouldn't be responsible to do so. 3. If I mistakenly sent money to a donation address of someone, is he/she obliged to return to me? No, because it was a donation. In the BitcoinStore case, a scammer tag was never given, so I can't say for sure what would have happened there, but even with that there was a huge difference between that issue and the bulanula issue. With bulanula, the overage was sent as part of a business transaction that was both already expected and negotiated prior to the transaction. Because of that, it was absolutely clear that a typo had been made when the amount that was sent was 10x what was expected. In addition, the sender was able to prove that they were the same person who negotiated the transaction. Would you see paying transaction fee is also a type of business transaction: I pay you fee, and you confirm my transaction. 111BTC is obviously a 222000x overpayment of the commonly agreed default 0.0005BTC fee. |
|
|
|
We all remember the case of bulanula ( https://bitcointalk.org/index.php?topic=483.msg841913#msg841913) and more recently for BitcoinStore ( https://bitcointalk.org/index.php?topic=131678.0) In both cases, someone mistakenly sent extra BTC to the alleged scammer. The sender obviously has full responsibility of the mistaken transaction. The alleged scammer then refused to return the BTC to the sender. This case is similar, the only difference is that the receiver is unknown before the block is miner. My questions are: 1. If the miner was found and refused to return the money, would he/she be labelled as scammer? 2. In this case, do those PPLNS users have the responsibility to return the extra earning? 3. If I mistakenly sent money to a donation address of someone, is he/she obliged to return to me? |
|
|
|
Is there a way to register watched addresses in the standard client?
Not yet. There is a pull request implementing bloom filters that should make that easy to implement. Or, could 'listunspent' be extended to take any non-wallet address as an optional parameter?
No. The reference implementation doesn't keep a master map of all addresses to unspent transaction outputs, and adding such an index for the small number of services that need to look up arbitrary addresses doesn't make sense. I'd suggest you -blocknotify and the getblock() RPC call to maintain your own index of address --> unspent txout. Even getblock is used, it only returns the txid, and gettransaction does not show the tx if is a non-wallet id. What should I do? Also, is there an ETC for the support of "watch-only addresses"? |
|
|
|
The private key shown in testnet mode is not compatible with satoshi client. The leading symbol should be "c" instead of "5": https://en.bitcoin.it/wiki/List_of_address_prefixesNot sure if this counts because it's minor problem in the testnet mode. Just forget the bounty if you think it is not an important one Another bug is rounding error in transaction fee. Sometimes when I sign a transaction with 0 fee, the client shows something like -0.00000001 (yes, a negative number) as fee. It seems just a cosmetic problem without affecting usability. Is it related to the use of floating-point number? How about 0.1 for both? The testnet keys are obviously not that important, but it was silly/unnecessary to be hardcoding that. And after all, I complain about not having enough testers, so it's worth fixing to make it easier for testers! Where did you see the -0.00000001 fee? Usually this occurs when value variables that have been set to sentinel UNINITIALIZED (== -1) and then somehow end up getting used anyway. There shouldn't be any problems with rounding, because I only use ints/longs for all values (in satoshis), and have a coin2str and str2coin function that converts between value and visual repr. However, I suppose it's still possible to have some -1's laying around... is it consistent enough you can tell me how to reproduce it? I don't think I've seen this myself... (I mean, I've seen it in the past, but I thought I had fixed all of them) Forget the bounty for the testnet one. Armory is so great and I don't think I should accept your out-of-pocket money. For the -0.00000001 fee, possibly because I have not updated the armory in my offline computer for a long time. So that might have been fixed. |
|
|
|
The private key shown in testnet mode is not compatible with satoshi client. The leading symbol should be "c" instead of "5": https://en.bitcoin.it/wiki/List_of_address_prefixesNot sure if this counts because it's minor problem in the testnet mode. Just forget the bounty if you think it is not an important one Another bug is rounding error in transaction fee. Sometimes when I sign a transaction with 0 fee, the client shows something like -0.00000001 (yes, a negative number) as fee. It seems just a cosmetic problem without affecting usability. Is it related to the use of floating-point number? There is a bounty of 0.1 BTC per new bug found in Armory 0.86.3-beta, up to a maximum of 3 BTC. This test drive ends on Jan 1, 2013. (at my discretion, I may pay more than 0.1 BTC, depending on the scope/impact/subtleness of the bug) Armory doesn't have enough testers. And the current testers are mostly Armory veterans that have been using it for a while and not doing new-user operations like creating new wallets, printing their one-time backups, etc. So I'm hoping that this post will get some fresh eyes on the app, and also give current testers some incentive to really try to break things. So, I'm going to test bug bounties for a short period of time, to see what kind of response I get. I may extend it in the future, if it turns out to be an efficient way to get testers and find bugs without too much dispute. And I do expect some dispute, but I'm going to try to be lenient about it. That's also why I've set an upper limit of 3 BTC, to limit the impact of this going terribly wrong... What qualifies as a "bug" is anything that impacts usability: I don't really want to give out bounties for grammatical improvements or missing punctuation in dialogs. Though maybe some would argue that I should. What I'm really looking for is things like checkboxes that should be disabled but aren't when using a watching-only wallet, selection dialogs with zero things to choose from, buttons that do nothing when clicked, etc. And obviously crashes, too. Here's a list of well-known bugs that don't count, because I already know about them and there's nothing I can do at the moment: - (1) Armory uses a lot of RAM
- (2) Loading Armory before Bitcoin-Qt is sync'd causes rapid connect-disconnect flickering
- (3) Lack of unicode support (coming soon, actually, just not in 0.86.3).
- (4) Windows systems always detect memory pool corruption and delete it.
- (5) Anything to do with the message-signing dialog -- it's queued to be revamped soon to be more useful (and match Bitcoin-Qt)
- (6) *.deb package is of "bad quality" according to newer versions of Ubuntu
- (7) Armory sometimes crashes after 0.5-6 days (it's not a memory leak, for sure)
- (8 ) Paper backup printing doesn't work in OSX. Please copy the data by hand or copy to another program where printing does work.
- (9) System tray icon does not disappear when Armory is closed (Windows only).
- (10) Unclickable link in version-check window
Here's what you need to do to collect the bounty: - (1) Be the first to post about a particular bug for the current testing version
- (2) If you don't include a payment address in your post, I will assume that I should send the 0.1 BTC to donation address in your signature
- (3) Either post relevant portions of the log file, or send me the log via email or PM (File-->Export Log File)
- (4) Have some patience -- I need to figure out the best way to run this operation. Also, I will send out payments in batches. If 4 people find 3 bugs each, I'll be sending out one tx paying 0.3 BTC to all four people at the end of the day or the next morning (you can request sooner if you're super anxious for some reason).
If you're interested please download the absolute latest: Armory 0.86.3-beta. It's not a testing version, but there won't be another testing version for a while, and I'm sure there's still plenty of bugs to be found here. UPDATE: Also, I've decided that anything in the testing branch is fair game. That is probably more bug-dense, but this little bounty drive will encourage me to do more internal testing before merging anything into that branch  (for 0.86.5-testing, I compiled and posted Windows-testing versions above).
Bugs reported (and thus, don't expect a bounty if you just found it): (1) UAC/admin needed even for local installation of Armory on Windows. (2) Wallets with P2Pool payouts crash Armory! (reported here). (3) Missing string replacement on dashboard when user is missing blk*.dat files. |
|
|
|
Would you want a traditional Chinese version? Some Hong Kong and Taiwan would feel irritated if they find a Simplified Chinese (they call it "broken Chinese") version but not a Traditional Chinese version. Of course, it is simple to convert a simplified version to a traditional one, so I don't think I'm eligible for claiming a bounty for this. But as said, I strongly recommend you to offer a traditional version if you are going to offer a simplified one. |
|
|
|
Your costs are known beforehand, and you know how much money you are risking.
FTFY  F TFY  LOL. Thanks. I should have seen that one.  |
|
|
|
Great idea!
bitcointip jl2012 +BTC0,05
Thank you. However, I cannot do it without devs support. Any comments from the dev team? |
|
|
|
It is a slang that has several meaning and not suitable for a banner like this. Anyway, I just want to point out that machine translation is not acceptable at all. You can not promote bitcoin with such bad translation More for you    |
|
|
|
|
Show Posts
