Search content
Sort by
Showing 20 of 63 results by gglon
Re: How probable is it to make typo & send [BTC] to a wrong address?
For technical background see https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
No, this is free market. Here, an innovation has increased the efficiency of mining and this is communicated to the customer via the price system. All exchanges involved are voluntary.
My bad. Of course it is free market. It is not preferable type of market for miners though, since their profit from tx fee tends to 0. This in the future, as previously noted by @jonny1000, won't allow to sustain large amount of mining power, decrease Bitcoin network value and create death spiral.
From miner perspective, in the short run, it is most profitable to include tx with fee that is grater than penalty from broadcasting this transaction. As I understand, as soon as block O(1) propagation is included this penalty is greatly reduced and amounts to almost 0. Therefore if miner is greedy it is best to include almost all transactions with non-zero fee as soon as possible. This however will destroy fee market -> fees will collapse to 0. This is not free market. Good well known analogy is situation when there is an unexpected surplus of some goods eg. food in the wake of some international sanctions. It is then not possible to sell all goods in the domestic market as the demand is not enough even if the wholesale price is 0. Therefore artificial limitation (destroying crops) is crucial for securing farmer revenues.
From miners perspective the best limitation is the one that brings miners the biggest revenue. That is probably when the fee is competitive with the other means of payment for small to medium types of transactions as those types of transactions are the most common ones. Therefore the ideal tx fee should probably be somewhere between $.1-$1.
If miners cooperate they have the power to limit soft maxblocksize by simply not mining larger blocks. But is this kind of cooperation possible in the view of the fact that greedy miner would mine all non-zero txs and have higher revenue? I think Gavin thinks it is possible so the hard maxblocksize role should be different. It should be just an upper limit of soft maxblocksize that miners can impose and that would guarantee network decentralization.
From miners perspective the best limitation is the one that brings miners the biggest revenue. That is probably when the fee is competitive with the other means of payment for small to medium types of transactions as those types of transactions are the most common ones. Therefore the ideal tx fee should probably be somewhere between $.1-$1.
If miners cooperate they have the power to limit soft maxblocksize by simply not mining larger blocks. But is this kind of cooperation possible in the view of the fact that greedy miner would mine all non-zero txs and have higher revenue? I think Gavin thinks it is possible so the hard maxblocksize role should be different. It should be just an upper limit of soft maxblocksize that miners can impose and that would guarantee network decentralization.
https://code.google.com/p/ghost-usb-honeypot/
Quote
Ghost USB honeypot
Ghost is a honeypot for malware that spreads via USB storage devices. It detects infections with such malware without the need of any further information. If you would like to see a video introduction to the project, have a look at this Youtube video.
The honeypot was first developed for a bachelor thesis at Bonn University in Germany. Now development is continued by the same developer within the Honeynet Project.
Ghost was recently selected for Rapid7's Magnificent7 program (see the press release). Our goal for the next year is to extend the honeypot to a USB protection system, i.e. a system that protects networked computer environments from the threat of USB malware.
Ghost is a honeypot for malware that spreads via USB storage devices. It detects infections with such malware without the need of any further information. If you would like to see a video introduction to the project, have a look at this Youtube video.
The honeypot was first developed for a bachelor thesis at Bonn University in Germany. Now development is continued by the same developer within the Honeynet Project.
Ghost was recently selected for Rapid7's Magnificent7 program (see the press release). Our goal for the next year is to extend the honeypot to a USB protection system, i.e. a system that protects networked computer environments from the threat of USB malware.
Because I believe in Satoshis values and in good people like Adam Back or Gregoy Maxwell.
Who helped creating and created such centralized system which bitcoin is. So that now it must be fixed by people like Mike, who want to make it more decentralized. ... I'm so angry I don't know how to say it.
It would be best if you use your anger as a motivation to carefully read what devs propose, consider all cons and pros of a given solution, compare it with your solution and then criticize it.So far all dev's solutions mentioned in this topic in no way limit bitcoin. They just expand its usage cases. They don't have to be perfect to be implemented. It's enough if they are better than what we currently have, and don't limit further improvements.
Qoheleth/everbody:
I think he is out of line, pushing for blacklisting.
I think he is out of line, pushing for SSL as part of this payment protocol.
I think he way is out of line, trying to force everybody to proof their identity by verifying their passport.
These are just some proposed solutions to the known problems (he is not pushing anything). If you know better solutions, please share, so that we will be able to choose the best solution available. I think he is out of line, pushing for blacklisting.
I think he is out of line, pushing for SSL as part of this payment protocol.
I think he way is out of line, trying to force everybody to proof their identity by verifying their passport.
The double spend "deposit" could be scaled with that probability. If only 5% of double spends succeed, then a merchant might demand a 10% double spend deposit.
Would you mind elaborating on how it would undermine the economy please? I am still quite uninformed on the intricacies of bitcoin.
Well, proof-of-stake as it is implemented in other cryptocurrencies is based on the annual inflation. Which means that PoS miner will gain on average x% yearly for keeping coins on active full node. To circumvent the effect of inflation, the tx fees are no longer paid to the miner - they are destroyed. Could it work to any degree if it was combined with Proof of Stake?
It could. But it would undermine the basics of bitcoin economy. Also the capital tends to be very unequally distributed - big banks (now exchanges), satoshi and so on. It solves the problem of full nodes number though, as everyone has some incentive to maintain one. Could it be possible to thwart secret chains by forbidding consecutive block verifications by a single mining address or something more complex?
No, that is not possible. Every such a mean can be easily circumvented. Especially if you can make use of virtually every single participating miner's PC. Centralization of mining pools which gain a slight advantage in terms of latency is something we need to prevent. I think the best method right now is just to educate the miners how potentially dangerous such centralization is.If drop this value from 1 block per second to 1 block per 30 second, then TPS will drop to 7, the same as current design 
You need to multiply blocksize b as well.
Re: The biggest problem with cold storage wallets is making sure that your address..
First, a minor part of the disagreement is that if I were to use the chess approach, I would select a much, much more obscure game to use for the passphrase data. With easily up to a million recorded games, that adds another 20 bits of entropy to my BrainSeed. And I think there is more obfuscation possible.
Of course further obfuscation is possible, making it more difficult to remember.But let's say that the BrainSeed has 75 bits of entropy. In normal BrainWallet cracking efforts, the target is to try derived addresses and check if there is BTC there. However, here the target is to find a passphrase that has to be used in conjunction with another passphrase. So really there is another 75 bits of entropy to deal with. And then the iterative process adds a lot of time delay between each cycle.
(If I understand you correctly) If you assume that cx-xxxx gives you 75bit then cy-yyyy doesn't add another 75bits since it is the same strategy and the same championships. So you only get entropy from repeating procedure: 2bits + 5 almost random numbers (14bits) + bip38 (20) = 36bits.
Second, my real desire here is to create a Brainwallet passphrase with high enough entropy that the standard cracking efforts won't uncover. And with BIP38, they would have to crack another high entropy passphrase to get at the encrypted private key.
Nowadays cracking techniques are becoming very sophisticated. Very huge computers are equipped with databases of human generated passwords revealed in many website leaks. As a result it is possible to uncover most popular obfuscation strategies, words, numbers used to generate password. It is very easy to underestimate current, and most importantly future AI capabilities in this area. Using non standard method is just another way to add entropy, and sth to remember. But it is very misleading to assume that computers wont try to break those non standard methods. And it is very easy to overestimate human generated password entropy.
My point is that while it is possible to create safe brainwallet with human generated obfuscation method, it is very difficult thing to do so. It may be slightly easier to remember, but they require a lot of time to be created. Also, while people can't calculate entropy properly they will never be sure if they created enough of it. Even if you come up with clever and provably safe instructions, most people would just not follow them properly (and the method will no longer be non standard).
Quote
But my approach is designed to help me generate the high entropy passphrase reliably without having to memorize things.
That is not possible. You have to remember something. Either these are words, symbols, functions, method of obfuscation - you still need to remember them. As a result you get passphrase with some entropy. But calculating this entropy is not that easy as just calculating length of the passphrase. You need to calculate entropy of obtaining that passphrase. And that entropy may depend on the information the attacker has about his target.
Quote
c1-0520 That simple BrainSeed reliably generates this passphrase:
Nf3Be2H30-0Be3cxD4a3Nc3NB5Ne5!QxE2Rac1BG5Bxf6NC4!Nxb6!RFd1Qe3!d5!rxd5
Nf3Be2H30-0Be3cxD4a3Nc3NB5Ne5!QxE2Rac1BG5Bxf6NC4!Nxb6!RFd1Qe3!d5!rxd5
So let's assume that attacker somehow get the information about you. Now we will estimate the enropy:
topic: chess matches - one of ~32 most likely topics - 5 bits of entropy
some popular game: one of ~128 most notable ones - 7 bits
shortcut of above 2 steps "c1" - one of ~16 most likely - 4 bits
common separator "-" - 2 bits
method of further obfuscation - one of ~64 most likely ones - 6 bits
first digit 0 or 1 - 1bit
three random digits - 10bits
bip38 - i don't know exactly but perhaps ~20 bits
So to sum up we get ~55 bits of entropy of brain wallet if the attacker know sth about you. If not, add ~5 bits and you get brainwallet with ~60bits. While it may be enough today, it is much lower than recommended standard of 128 bits. And I wouldn't recommend to choose anything below 80bits.
While above calculation may seem to overestimate the attacker capabilities, you need to remember that passwords are being broken by highly intelligent AI which is aware of all common human password choosing strategies.
You also have to take into consideration that when humans are told to follow your procedure, they would probably choose sth like: take first 20 words of bible, choose every 2nd, and add some 2 digit nr to get <40bit brainwallet entropy, which is a disaster.
That is way it is recommended just to create 12 random word (128bit) seed. Then you can bip38 it (~20) with 4 random words from seed(~40) and hide it physically (~20) to get total ~80bits (in case you forget the whole 12 initial words).
If you want to be safe I suggest to multiplicate wallet.dat file into many copies to fill the mass storage (m-disc) to the limit. Then even if say >90% (depends on the storage size and luck) is corrupted, it's still possible to recover data.
If you prefer to have one solid copy use this: http://www.youtube.com/watch?v=qpOV6r2vy9Y
though I don't know if the 'printer' stores anything in the memory.
If you prefer to have one solid copy use this: http://www.youtube.com/watch?v=qpOV6r2vy9Y
though I don't know if the 'printer' stores anything in the memory.
2013-06-17 - US GAO.gov - Virtual Currencies and Economies Report
United States Government Accountability Office
Virtual Economies and Currencies:
Additional IRS Guidance Could Reduce Tax Compliance Risks
GAO-13-516, May 15, 2013
released on Jun 17, 2013
http://gao.gov/products/GAO-13-516
Direct link:
http://gao.gov/assets/660/654620.pdf
txt version:
http://gao.gov/assets/660/655226.txt
Audio interview by GAO staff with Jim White, Director,
Strategic Issues on Related GAO Work: GAO-13-516
http://www.gao.gov/assets/660/654443.txt
Virtual Economies and Currencies:
Additional IRS Guidance Could Reduce Tax Compliance Risks
GAO-13-516, May 15, 2013
released on Jun 17, 2013
http://gao.gov/products/GAO-13-516
Direct link:
http://gao.gov/assets/660/654620.pdf
txt version:
http://gao.gov/assets/660/655226.txt
Audio interview by GAO staff with Jim White, Director,
Strategic Issues on Related GAO Work: GAO-13-516
http://www.gao.gov/assets/660/654443.txt
How Much: calculating...
Let me remind you of @kjj idea, which I find interesting:
When we do need to increase the limit, I would propose the following rules: Block max size increases iff at the time of difficulty change, the sum of the size of the last 2016 blocks is > (1814 * block_max_size). If size increase is indicated, block_max_size+=(block_max_size>>4). I'll leave the implications as an exercise for the reader. 1814 and 4 are magic numbers, they could be changed, but I suggest they not be any smaller than specified.
Though I would consider adding some high hard limit too (100MB-1GB)