Protocol rules allows to choose other branch if it has more accumulated difficulty, even if it is rooted in old blocks before checkpoints. Checkpoints override those rules - they essentially change protocol specification. By adding new checkpoint - you are forking protocol specification.
Choice of checkpoints should be done decentralized - by voting, and Bitcoin already has voting mechanism - vote by computing work. But if voting happens by hard checkpoints, selected by dozen of people - then it is centralized, with all bad sides of centralization.
It's an optimization that can be disabled with a command line switch. |
|
|
|
|
P2P exchanges that don't solve the fiat moving problem are pointless wastes of time.
|
|
|
|
|
Use Coinbase to buy bitcoins, then immediately withdraw them through a suitable mixing service to your own wallet.
|
|
|
|
Log file? I think it got clobbered in the downgrade. Was in a hurry and didn't think to save it. Also, did you recently add a lot of addresses, wallets, etc? There's a known problem if you have tons of addresses, it can be slow when new blocks are coming in. That's going to be fixed in 0.91. The only wallet I've added recently was the one you guys were handing out in Vegas... Also, try "Help"-> "Rebuild and Rescan Databases"
That's something else - even when I think I did a clean shutdown of Armory it still ends up doing the full blockchain scan at least half the time. |
|
|
|
|
I've never used Instawallet but I've been watching this thread.
I'll just note that, based on extensive examples. the way the people involved respond to their (former) customers is atrocious, and based on their behaviour I'll never be involved with any business they are involved in.
|
|
|
|
|
I had to downgrade to 0.88 last night because the UI had become slow and unresponse to the point at which I could create a transaction and click "send" and nothing would happen.
|
|
|
|
I think we should make any transaction with >0.1 XBT fee as non-standard. (0.0001 XBT/kB * 1000kB = 0.1 XBT). Do you mean a limit in absolute terms, or in per-kB terms? |
|
|
|
My btcd node has been seeing transactions with strange signatures recently. # grep -R -C1 signature /var/log/everything
08:31:46 2013-12-14 [WRN] SCRP: can't parse signature from string: signature R is negative
08:31:46 2013-12-14 [WRN] CHAN: validate of input 0 failed: signature R is negative
08:31:46 2013-12-14 [WRN] CHAN: tx b5043a18e3833907d4e92d00cbfdd220f5f953a07d26699ad7470c719c91cc65 failed input 0, err signature R is negative
08:31:46 2013-12-14 [ERR] BMGR: Failed to process transaction b5043a18e3833907d4e92d00cbfdd220f5f953a07d26699ad7470c719c91cc65: signature R is negative
08:31:46 2013-12-14 [WRN] SCRP: can't parse signature from string: signature R is negative
08:31:46 2013-12-14 [WRN] CHAN: validate of input 0 failed: signature R is negative
08:31:46 2013-12-14 [WRN] CHAN: tx 03154590218aa7067e8177cec4e565dc283c74bea5fedc17048578b4860a32e2 failed input 0, err signature R is negative
08:31:46 2013-12-14 [ERR] BMGR: Failed to process transaction 03154590218aa7067e8177cec4e565dc283c74bea5fedc17048578b4860a32e2: signature R is negative
08:31:48 2013-12-14 [WRN] SCRP: can't parse signature from string: signature R is negative
08:31:48 2013-12-14 [WRN] CHAN: validate of input 0 failed: signature R is negative
08:31:48 2013-12-14 [WRN] CHAN: tx b5043a18e3833907d4e92d00cbfdd220f5f953a07d26699ad7470c719c91cc65 failed input 0, err signature R is negative
08:31:48 2013-12-14 [ERR] BMGR: Failed to process transaction b5043a18e3833907d4e92d00cbfdd220f5f953a07d26699ad7470c719c91cc65: signature R is negative
08:31:49 2013-12-14 [WRN] SCRP: can't parse signature from string: signature S is negative
08:31:49 2013-12-14 [WRN] CHAN: validate of input 0 failed: signature S is negative
08:31:49 2013-12-14 [WRN] CHAN: tx ceaa241316a03719e997105996d033c2a856f999e4ccf637b79c8cd2ea98dc65 failed input 0, err signature S is negative
08:31:49 2013-12-14 [ERR] BMGR: Failed to process transaction ceaa241316a03719e997105996d033c2a856f999e4ccf637b79c8cd2ea98dc65: signature S is negative
08:31:49 2013-12-14 [WRN] SCRP: can't parse signature from string: signature R is negative
08:31:49 2013-12-14 [WRN] CHAN: validate of input 0 failed: signature R is negative
08:31:49 2013-12-14 [WRN] CHAN: tx 6f322d83070091e237fc6eaa12933575dd87933513ce68205014e751eaa0ffe5 failed input 0, err signature R is negative
08:31:49 2013-12-14 [ERR] BMGR: Failed to process transaction 6f322d83070091e237fc6eaa12933575dd87933513ce68205014e751eaa0ffe5: signature R is negative
08:31:52 2013-12-14 [WRN] SCRP: can't parse signature from string: signature R is negative
08:31:52 2013-12-14 [WRN] CHAN: validate of input 0 failed: signature R is negative
08:31:52 2013-12-14 [WRN] CHAN: tx d814630684cc1c63a363f5be8c2efb6858a1221e9b1b61c4c8432c13e63cd811 failed input 0, err signature R is negative
08:31:52 2013-12-14 [ERR] BMGR: Failed to process transaction d814630684cc1c63a363f5be8c2efb6858a1221e9b1b61c4c8432c13e63cd811: signature R is negative
08:31:52 2013-12-14 [WRN] SCRP: can't parse signature from string: signature R is negative
08:31:52 2013-12-14 [WRN] CHAN: validate of input 0 failed: signature R is negative
08:31:52 2013-12-14 [WRN] CHAN: tx 6f322d83070091e237fc6eaa12933575dd87933513ce68205014e751eaa0ffe5 failed input 0, err signature R is negative
08:31:52 2013-12-14 [ERR] BMGR: Failed to process transaction 6f322d83070091e237fc6eaa12933575dd87933513ce68205014e751eaa0ffe5: signature R is negative
08:31:52 2013-12-14 [WRN] SCRP: can't parse signature from string: signature R is negative
08:31:52 2013-12-14 [WRN] CHAN: validate of input 0 failed: signature R is negative
08:31:52 2013-12-14 [WRN] CHAN: tx ac22ed3db9ff16664c144f7c5aa71f296c7e87b3a9e3c03624d7dfdc124125ac failed input 0, err signature R is negative
08:31:52 2013-12-14 [ERR] BMGR: Failed to process transaction ac22ed3db9ff16664c144f7c5aa71f296c7e87b3a9e3c03624d7dfdc124125ac: signature R is negative
08:31:53 2013-12-14 [WRN] SCRP: can't parse signature from string: signature S is negative
08:31:53 2013-12-14 [WRN] CHAN: validate of input 0 failed: signature S is negative
08:31:53 2013-12-14 [WRN] CHAN: tx ceaa241316a03719e997105996d033c2a856f999e4ccf637b79c8cd2ea98dc65 failed input 0, err signature S is negative
08:31:53 2013-12-14 [ERR] BMGR: Failed to process transaction ceaa241316a03719e997105996d033c2a856f999e4ccf637b79c8cd2ea98dc65: signature S is negative
08:31:54 2013-12-14 [WRN] SCRP: can't parse signature from string: signature R is negative
08:31:54 2013-12-14 [WRN] CHAN: validate of input 0 failed: signature R is negative
08:31:54 2013-12-14 [WRN] CHAN: tx ac22ed3db9ff16664c144f7c5aa71f296c7e87b3a9e3c03624d7dfdc124125ac failed input 0, err signature R is negative
08:31:54 2013-12-14 [ERR] BMGR: Failed to process transaction ac22ed3db9ff16664c144f7c5aa71f296c7e87b3a9e3c03624d7dfdc124125ac: signature R is negative
08:37:24 2013-12-14 [INF] BMGR: Processed 1 block in the last 8m12.4s (207 transactions, height 274809, 2013-12-14 08:37:06 +0000 UTC) |
|
|
|
|
I've refrained from reporting threads for just being dumb and/or FUD, but if that's cool I'll start doing it.
|
|
|
|
|
Many threads are just repetitive FUD to be honest, and it would be nice to have some place to put them them that can be easily ignored.
|
|
|
|
|
A lot of political and philosophical forums have a versus category. An example of this might be a section of an atheist forum where people can debate religion, or a section of a communism forum where people can debate the free market.
How about adding a child of Bitcoin Discussion called Versus, where all the "Bitcoin is doomed/deflation will destroy us all/my grandmother will never accept it/will be crushed by governments" etc threads can be moved?
|
|
|
|
|
Another warning might be in order when the user clicks on "Request payment to this address" on an address which has previously been used.
|
|
|
|
2) NSA diddling the chips during manufacture without Intel even knowing by flooding their corp with agent employees.
I wonder how much of Microsoft's reputation for building insecure software is due to this effect. |
|
|
|
This would be great, and a huge advantage to the network and for security of exchanges and customers alike.
But will the exchanges do this?
It may be they already sell BTC they don't have. These exchanges are not run by paragons of virtue!
Getting BTC-e, Stamp and Gox all doing this looks tough - UNLESS they are more afraid of security issues than being found out for what they are (potentially) hiding from the market. It is possible on balance this is the case.
It would be a leap forward if it worked - but it will take the will and a lot of work.
EDITED to remove thoughts on how they could sell coins they don't actually have - no need to freak everyone out!
In order to get the ball rolling it's only necessary to get three sites to join the first pool. Once that happens, we've got a method for adding new members to the pool one at a time (up to the Bitcoin protocol maximum of 20). So maybe you don't start with BTC-e, Stamp and Gox to begin with. Perhaps you convince LocalBitcoins, CampBX, and Coinfloor. Then you make it a competitive disadvantage to not join the pool by heavily emphasizing how much more secure deposits are in the exchanges that join a pool versus those who do not until the remaining exchanges either join up, or experience a run on the bank which reveals their insolvency. |
|
|
|
|
Coin control is orthogonal to this.
Users should receive a warning any time they are about to perform an action that permanently reduces their privacy, such as combining inputs from multiple addresses.
|
|
|
|
There's only so many coins and they need to actually have them (or the cooperation of gox to be able to sell coins they don't have). If all the major exchanges join a voting pool there's no way for them to sell coins they don't have without being immediately detected. |
|
|
|
|
How about an optional mode where Armory will throw a warning before executing a transaction any time it's not possible to spend the desired amount of bitcoins without combining inputs from different addresses?
|
|
|
|
1) Lawsuit against FINCEN to reclassify bitcoin as commodity/virtual goods.
2) Maintaining database of lawyers who will specialize in bitcoin related cases.
EFF is a good example of similar organization.
It's a waste of money that could be better used to relocate to a less-hostile country. |
|
|
|
They can block services like exchanges and with them, all the coins they have
Not if those services hold customer bitcoins in a voting pool, they can't. |
|
|
|
|
Edd has pictures of Stephanie holding the leash.
|
|
|
|
|
Show Posts
