Where will you people stay? The Prague conference had an agreement with a hotel, this one does not seem to have made any agreement, but the site does mention this hotel: http://www.imperialhotels.co.uk/Apparently it's close to the conference venue. covers a number of hotels in the area. I booked at the one called President (Russell Square, London, WC1N 1DB), which is very close to the venue. Oh, thanks for clarifying. So those names are not just room categories, but different hotels, and the closest one to the conference is the Royal National whose single rooms are at 81 pounds per night, that's it? Why did you book in the President and not the Royal National if you don't mind me asking? |
|
|
|
Where will you people stay? The Prague conference had an agreement with a hotel, this one does not seem to have made any agreement, but the site does mention this hotel: http://www.imperialhotels.co.uk/Apparently it's close to the conference venue. |
|
|
|
|
There is no strong need to mix the "mobile wallet" and "secured, dedicated device" use cases like Ellet intended to do. These are different use cases, that may be separate.
Competing with smartphones in the mobile wallet use case would be difficult since people already carry the phone around all the time. I believe most people wouldn't like to carry an extra device just because bitcoin.
A cheap, dedicated device to keep at your home and use it to access your main wallet is still interesting though. Once in a while you make a transfer from this device to your mobile wallet, like when you get cash in ATM. Most of you money remains secure in an almost-unhackable device, and you only carry a small amount you can afford to lose in your unsafe smartphone.
|
|
|
|
We put a lot of effort into avoiding the possibility of invalidating a chain of transactions. Newly mined coins aren't valid until 100 blocks have passed (120 in practice, but the hard requirement is only 100). If not for that requirement, a miner could create some coins, spend them, the recipient could spend them, etc, and then a shallow reorg would invalidate the coinbase, and break the whole chain. People should wait for sufficient confirmations to avoid the problem, but they don't, so the network makes it impossible.
Now, what happens when scripts can be either valid or invalid depending on which block they are in? The same whole mess that we were trying to avoid. The invalidated transactions might not be valid for inclusion in the next block, and the transactions that spent them are also possibly invalid.
And yes, I know that we could maybe come up with yet another special case in the script system so that the block height can only be checked with a greater than operation, but ugh. Also, you end up with a race if the reorg goes back to before the script would have become valid, which might only be two or three blocks, which happen on a regular basis already when there is no practical way to profit from them.
The same "invalidating chain of transactions" scenario may already happen if people accept 1 or 0 confirmation transactions. The difference with coinbase is that the money totally vanishes in a reorg, while in these scenarios it doesn't disappear, it may still be included in a future block. And still, I'm not even that sure the protocol itself should forbid coinbase from being spent right away. Perhaps people should be allowed to take the risk of accepting a transaction whose money may suddenly disappear. I believe miners in a pool would appreciate if they could withdraw their money right away, for example. Anyways, just wondering. I realize people will not want to touch this, and they have a good reason not to. |
|
|
|
You create a transaction that will not be valid for a month (whatever) and broadcast it. Then an attacker gets in and steals the private key for that address. They can create a new transaction that sends the money to their own address. Honest nodes will consider that a double spend and refuse to relay it.
No... honest nodes should consider the legit owner is cancelling the transaction. nLockTime shouldn't be used to protect against private key loss. Since you'll have to secure the target key of the transaction anyway, why don't you secure the current key the same way? The most notable use case I see for nLockTime is inheritance. You transfer your money to your heirs in a time locked transaction. But it's still your money, you may cancel the transaction and spend the money some other way. In case you die before doing it, then your heirs will eventually get the money. |
|
|
|
If your bitcoins are stolen this is your and only your fault!
Of course, the thief is totally innocent.  |
|
|
|
No, there is no way to get the block number in a script. People keep asking for it, but it wasn't left out by accident, it is missing for a reason. (Please think about how the network handles block reorgs for a while before you ask...)
Pardon my ignorance, but all I know about reorgs is that the block that loses the race gets ignored. Its transactions are not valid anymore and must be included in another block. Why does that makes it impossible to get the block number, or other block header data, in a script? I mean, I understand it might be complicated and perhaps not worthwhile doing. But it's not impossible, is it? nLockTime has some issues. For example, if you lose your keys, the network could see two transactions spending the same output, one locked until some time in the future, and one not locked. If the unlocked one has more fees, miners might just take it instead of the locked one.
That's exactly how I pictured nLockTime should work: you should be able to cancel the scheduled transaction. It does not solve what OP wants, of course. |
|
|
|
|
Question: is there a way, in bitcoin script, to get the block number?
If this was possible it would be possible to make what OP asks with a custom transaction script.
|
|
|
|
|
Not exactly what you mean, but there's this feature, not yet enabled unfortunately, called nLockTime. It would allow you to specify a minimum block height for a transaction. For example, you say a transaction X should not enter the blockchain before block 210K. You may release the tx now, but it won't be accepted until then.
|
|
|
|
I don't know if there would be any interest in an exchange with 100% cold storage and delayed withdraws.
Most bank transfer take ~24h, so I'd say people might tolerate if you manage to execute them daily. Assuming you explain the reason well enough. EDIT: A very-small hot wallet, which would frequently get depleted, but that could be refunded daily too, might be even better. By very-low I mean with an amount that you could assure you can refund from your own pockets in case of a hack. |
|
|
|
"Bitcoin" has no phone number, that confuses the hell out of old world people.
What's the phone number of "e-mail"? My parents manage to use it, though. I'm not sure I'd like to see some "legal organization" claiming to represent Bitcoin... well, let's see. |
|
|
|
One thing is certain, however: a higher bitcoin velocity would indicate health in the BTC economy as a whole but would have a disappointing effect on exchange rate for the speculators.
A healthier BTC economy might also imply in better BTC-quoted investment opportunities (stocks, bonds etc) in which these speculators could invest. |
|
|
|
All things equal, and increas in velocity implies a decreasing time preference, meaning people in general are more inclined to spend now than wait for a better deal.
No, again this is comparing apples and oranges.  Savings != money. A lower time preference imply less savings. But savings have many forms, not only storing money. A higher velocity might simply imply people are more "certain" about where to place their money. If you could know everything for sure, you'd likely never hold liquid money. As soon as you'd receive some, you'd exchange it for something better right away (either an investment or something you know you'll need/want). We keep liquid money because we cannot be 100% sure of when we'll need it, nor how much. Neither we can be 100% about which investments are good or bad. Keeping money is a form of protection. Velocity might also be linked to the actual speed in which we are capable of transacting, as you and others have noted. The fact that we can easily transfer any amounts of bitcoin anywhere in the world in ~1h will probably contribute to a higher velocity. |
|
|
|
Thank you for that link, it's a very interesting text! |
|
|
|
The black market economy is estimated to total $10,000,000,000,000.
If Bitcoin takes over...
.01% of the black market, then 1 BTC = ~ $47
1% of the black market, then 1 BTC = ~$4,761.90
10% of the black market, then 1 BTC = ~$47,619.05
Your math doesn't make sense, but you're not the first that I see making such mistake so I decided to reply. You're comparing apples and oranges. When people estimate that black markets are "10T USD large", they're trying to estimate the amount of production outputted by such black markets. A summed value of all goods and services produced, normally in a year time. This has nothing to do with the amount of money that circulates in this market in a given instant, i.e., its "money supply". For example, an (arguable) estimation of US total economic production is it's GDP of ~14T if I'm not mistaken. That's much more that the entire USD money supply. Granted, you must better define "money supply" as many things may be used as money... but if you take for example the M2 aggregation for USD, that's around ~10 bi according to wikipedia. More than 1000 times lower than the GDP...EDIT: Oups, my mistake, USD M2 is actually close to 10T... so yeah, not that far from the GDP, but that's still just a coincidence.  The M1 is lower. And bitcoin's 21M cap is the M0 of bitcoin. USD M0 is around 2,8T. Anyway, my point is, money supply != economic production in a year. You can't compare "black market production" with bitcoin's monetary base of 21M and reach any meaningful number. |
|
|
|
Someone is saying that with your deterministic wallet you can create a watching wallet that generates a sequence of public keys that matches the sequence of private keys generated elsewhere. Is that true? And if it is, how the heck do you do it?
I'm not a cryptographer so perhaps someone else can answer you with more details, but from what I've read around here, the seed is an ECDSA key pair itself. A sort of "master key". So, you use the master private key for the private key series, and the master public key for the public key series. It's a nice feature of ECDSA, apparently. |
|
|
|
Women are inherently disadvantaged on a free market. Because they need to take breaks during pregnancies and the time after
Or, alternatively, they are inherently advantaged because they have the option to become pregnant and men have no such option. A woman does not have to become pregnant unless she believes the advantages outweigh the disadvantages. +1. They have a choice men don't have. I'd never call that a "disadvantage". By the way, in developed nations, there's no significant difference between men and childless women, in what concerns career, salaries etc. Also, OP should read some of Wendy McElroy texts if he believes free markets are unfair to women. |
|
|
|
There is nothing special about 0 that makes it less likely than any other hash result.
But the thing is that any random number you pick will just never happen. (assuming it was really random, and not something you just took from the already existing chain). That same way, there should never exist a collision in the chain, or anywhere else in the world. The sun will go supernova much before that happens. |
|
|
|
again and again and again people ask if the bitocin network could crack sha256
If you see somebody talking about bruteforcing SHA-256, just show him this: https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.htmlOne of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)
Given that k = 1.38×10-16 erg/°Kelvin, and that the ambient temperature of the universe is 3.2°Kelvin, an ideal computer running at 3.2°K would consume 4.4×10-16 ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.
Now, the annual energy output of our sun is about 1.21×1041 ergs. This is enough to power about 2.7×1056 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2192
|
|
|
|
|
Show Posts
