let´s say i have 1000 bitcoins and from investors that don´t want to bother with exchanges for 12 months. to keep them safe from theft, they should be stored offline. but if i want to keep a "sell" order about 20% below the current price to minimize the loss in case of crash, those coins need to be at the exchange. which is the more rational choice ?
You can't "keep" a sell order about 20% below the current price, because it will become a market order selling at current price
|
|
|
Are the private keys formed by the escrows in series or parallel? Private keys aren't formed by anything. They are private keys (random 256 bit numbers). Multi-sig simply requires/allows more than one private key to be used. Thanks, so when the 20-of-20 transaction is set up do the escrows involved in it need to sign the 20-of-20 transaction request in series or can this be done in parallel? In series but the order doesn't matter. Can't be parallel.
|
|
|
How could you derive the public key without using a computer at all? Doing it by hand? That's too dangerous as any minor mistake in calculation will be fatal.
Which is why the benefit is theoretical. You don't need to do it by hand. Just buy a raspberry pi, never connect it to the internet, calculate the public key of a brain wallet, and throw the pi to incinerator
|
|
|
In conclusion, you idea is either providing slim improvement to security, or extremely inconvenient, or both. So why don't you simply use cold wallet, which is inconvenient but perfectly safe? Soon we will have tamper-proof hardware wallet, which will be convenient and safe.
And that's really what this comes down to: what use cases would an "intent" system have over other solutions that don't require changing the protocol? It's not usable for a hot wallet, so that case is out. It would work well for a warm wallet, but since there are plenty of viable alternatives to preventing theft (using paper wallets, hardware wallets, or 2-factor wallets), I only really see it as a way of fixing mistakes, which is a pretty rare use case. But... what if you think at the enterprise level? Where this ends up potentially being useful is in the hot wallet of a company that is monitoring their hot wallet 24/7/365. Imagine if an exchange got hacked. No longer would they require expensive "trusted" hardware that verifies that a transaction is valid and signs it. They just need every one of their receiving addresses to be a delayed-transfer address and have an understanding with their customers that they can't get to their money for a few hours. THIS is where an intent system would truly excel. If the customers are happy with a few hours delay, the exchange can simply process withdrawal request manually with a cold wallet. So the only useful scenarios of the proposed system would be fixing mistake and fighting against dishonest staff. I think these risks could be minimized by multisig or other existing solutions. EDIT: actually the proposed system is not a good measure against dishonest staff, as the staff could work with the hacker, or be the hacker himself. That means you still need another staff / a trusted computer to crosscheck the actions. So why not simply use multisig cold wallet? I don't disagree with the idea that this would provide marginal security over what we already have. But, there is added security with this. Basically, this is a way of doing multisig without requiring that one of the private keys ever touch an electronic device unless something bad happens. Theoretically, the CEO of a company could memorize a private key and derive its public key without a computer, reducing the number of people and things that have to be trusted - considerably. You could prove that it is impossible for someone to steal from you even if they hack every electronic device in the world. Is a paper wallet practically better than storing your private keys on a USB drive? No. But it's pretty cool to think about. The same applies to this idea. It would be interesting to see an alt-coin with this, though. How could you derive the public key without using a computer at all? Doing it by hand? That's too dangerous as any minor mistake in calculation will be fatal.
|
|
|
In conclusion, you idea is either providing slim improvement to security, or extremely inconvenient, or both. So why don't you simply use cold wallet, which is inconvenient but perfectly safe? Soon we will have tamper-proof hardware wallet, which will be convenient and safe.
And that's really what this comes down to: what use cases would an "intent" system have over other solutions that don't require changing the protocol? It's not usable for a hot wallet, so that case is out. It would work well for a warm wallet, but since there are plenty of viable alternatives to preventing theft (using paper wallets, hardware wallets, or 2-factor wallets), I only really see it as a way of fixing mistakes, which is a pretty rare use case. But... what if you think at the enterprise level? Where this ends up potentially being useful is in the hot wallet of a company that is monitoring their hot wallet 24/7/365. Imagine if an exchange got hacked. No longer would they require expensive "trusted" hardware that verifies that a transaction is valid and signs it. They just need every one of their receiving addresses to be a delayed-transfer address and have an understanding with their customers that they can't get to their money for a few hours. THIS is where an intent system would truly excel. If the customers are happy with a few hours delay, the exchange can simply process withdrawal request manually with a cold wallet. So the only useful scenarios of the proposed system would be fixing mistake and fighting against dishonest staff. I think these risks could be minimized by multisig or other existing solutions. EDIT: actually the proposed system is not a good measure against dishonest staff, as the staff could work with the hacker, or be the hacker himself. That means you still need another staff / a trusted computer to crosscheck the actions. So why not simply use multisig cold wallet?
|
|
|
This is not technically true, I mentioned that a failsafe address is important because it allows the coins to always be able to be transferred to it instantly. If a user deems that they need their coins right now They always have this option. The thief would necessarily have to know the private key of both addresses to spend the coins instantly too. Case in point, it's easier to hide multiple private keys versus just one. Doesn't mult-sig do this? Yes, but multi-sig doesn't notify you if a thief attempts to spend your coins.
So theoretically, the failsafe address should be a cold address or it won't be safe enough. When you need to spend a coin, you need to send the coins to the failsafe address first, then open your cold wallet (e.g. Armory) to send the coin out. So why don't you simply put your coins at the cold failsafe address at the very beginning?
|
|
|
Seeing as Bitcoin-Qt is the "reference client", what are you suggesting. Is there some other protocol definition beyond the rules enforced by bitcoin-qt?
Here: https://bitcointalk.org/index.php?board=37.0To enforce an incompatible protocol change (aka hard-fork), you need to modify all these alternative clients, not just bitcoind or bitcoin-qt
|
|
|
1.) The coins can be spent, but the pending transaction is broadcast and a specified amount of time (or confirmations) must pass before the coins actually leave your wallet. 2.) Sending the transaction again overrides the first, and again renews the pending withdrawal time. 3.) A failsafe address is added that allows the coins to immediately be spent to it. (very important)
This may somehow increase the safety, but it just makes you more trouble. Due to the risk of chargeback, no merchant will deliver before your transaction becomes permanent. To archive reasonable safety, the specified time must not be too short (e.g. the thief may steal your coins when you are sleeping). If the specified time is too long, you cannot spend your coins in a reasonable time. If the specified time is too short (e.g. 30 minutes), the increase in security is very slim and you have to wake up every 30 minutes to monitor your bitcoin balance. In conclusion, you idea is either providing slim improvement to security, or extremely inconvenient, or both. So why don't you simply use cold wallet, which is inconvenient but perfectly safe? Soon we will have tamper-proof hardware wallet, which will be convenient and safe.
|
|
|
Is BitInstant no longer giving out Bitstamp codes? I only see gox, ppusd, coinapult, virwox, bitcoin, and vouchx, and I believe depositing a vouchx into Bitstamp requires Aurumxchange, which charges a 2% fee...
I think they have it from time to time. It's running out of stock because they are cheap then aurumxchange
|
|
|
Your suggestions require total protocol change, not just bitcoin-qt. (if you think bitcoin-qt = bitcoin network, that's completely wrong), and that will provide only very limited improvement in security.
Without a protocol change, your grandma can still use bitcoin at a safety level comparable to cash and credit card. The solution is temper-proof hardware wallet. I think we will have one very soon.
|
|
|
Could the government shutdown your "off-chain solution"? If yes, forget it. If no, why?
|
|
|
Nodes discover their own external address by various methods. Nodes receive the callback address of remote nodes that connect to them. Nodes connect to IRC to receive addresses. Nodes makes DNS request to receive IP addresses. Nodes can use addresses hard coded into the software. Nodes exchange addresses with other nodes. Nodes store addresses in a database and read that database on startup. Nodes can be provided addresses as command line arguments Nodes read addresses from a user provided text file on startup https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery谢谢,我英语水平不行。看了一下,好像还是需要先连一下irc服务器。如果irc服务器断了,bitcoin客户端就无法发现其它节点了。 IRC在0.6以後已經不用了. 現在用DNS: bitseed.xf2.org dnsseed.bluematt.me seed.bitcoin.sipa.be dnsseed.bitcoin.dashjr.org 那这些DNS如果都断了或者被封锁了,bitcoin客户端就无法发现其它节点了。 你可以手動輸入地址
|
|
|
Nodes discover their own external address by various methods. Nodes receive the callback address of remote nodes that connect to them. Nodes connect to IRC to receive addresses. Nodes makes DNS request to receive IP addresses. Nodes can use addresses hard coded into the software. Nodes exchange addresses with other nodes. Nodes store addresses in a database and read that database on startup. Nodes can be provided addresses as command line arguments Nodes read addresses from a user provided text file on startup https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery谢谢,我英语水平不行。看了一下,好像还是需要先连一下irc服务器。如果irc服务器断了,bitcoin客户端就无法发现其它节点了。 IRC在0.6以後已經不用了. 現在用DNS: bitseed.xf2.org dnsseed.bluematt.me seed.bitcoin.sipa.be dnsseed.bitcoin.dashjr.org
|
|
|
AML makes no sense. One can provide this service with offshore hosting, or even as tor hidden service.
|
|
|
why can't i withdraw my bitcoins from btc-e?
Perfectly ok for me
|
|
|
Despite or perhaps in spite of, what others say I find it increasingly difficult to dislike you. I resisted the ignore button till now but this post pushed me over. Wasting my time to go to bitcoincharts looking for even tiny evidence of something... +1 I did exactly the same
|
|
|
交易平台的技術水平較低, 所以可以大量開設. 看ASIC, 中國就只有兩組, 是因為技術要求高
|
|
|
我本來以為這個是笑話, 現在不能不相信了. CNY/BTC 交易所現在有 btcchina, fxbtc, bitxf, bter, rmbtb......還有沒有其它我不知道的? EDIT: 還有bitsea, 42btc, hibtc ------------------------------------------------ 轉載: 猶太人與中國人的不同經營之道 第一個猶太人來到小鎮上開了個加油站,生意很旺; 第二個猶太人來了,發現加油站生意很不錯,想到加油站的客戶需要吃飯,所以投資開了個餐館; 第三個猶太人來了,想到來小鎮的人多了需要住宿,於是開了個飯店; 第四個猶太人又發現住店的人需要生活用品,於是開了超市; 第五個,第六個……來的人越來越多,吃飯住宿旅遊經商的人又需要加油,於是加油站、餐館、飯店、超市的生意相繼更旺了,逐步小鎮就成了個一個經濟繁榮的小鎮,很多猶太人都富裕了。 第一個中國人來到小鎮上開了個加油站,生意很旺; 第二個中國人來了,發現第一個人投資的加油站生意真令人羨慕,趕緊開了第二個加油站; 第三個中國人又來了,看見前面2個同胞的加油站生意很好妒嫉得眼紅,火速開了第三個加油站; 第四,第五個同胞過來都是一樣,開加油站還打折促銷……最後惡性競爭,然後紛紛倒閉,小鎮又回到原點…… 成功,不在於你贏過多少人,而在於你與多少人分享利益,幫過多少人。你與之分享的人越多,幫過的人愈多,服務的地方愈廣,那你成功的機會就愈大。
|
|
|
So miners are now able to generate blocks incompatible to old clients. Has the first incompatible block generated (i.e. hardfork happened)?
|
|
|
So I have a hidden address in my wallet?
Yes, just search "change address"
|
|
|
|