Bitcoin Forum
August 23, 2024, 11:47:50 PM *
News: All versions of Windows are affected by a critical security bug; make sure you update.
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 [305] 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 ... 405 »
6081  Other / Politics & Society / Re: Human Augmentation on: August 17, 2011, 07:43:45 PM
I don't see why not... if someone wants to make themselves a robot or a superhuman, that's up to them.
What if everyone becomes superior through augmentations but the poor -- whom can't afford it -- are left in the cold? They would be inferior and would have to settle for lesser jobs. Is that really fair?
Sure it's fair.  If the poor want to be augmented, they can work their butts off and save their money to get augmented.  It's like choosing to get a college education or not.  Yeah, it costs a lot of money, but if you want, you can work your butt off, save your money, pay for your tuition (or be stupid like me and just get student loans), and put yourself through college so that you can get a better job.
6082  Other / Politics & Society / Re: greed is good? on: August 17, 2011, 07:22:50 PM
Greed is good.

Rational greed that is. There's nothing wrong with striving to gain because it only builds society in the end. In order to gain valueone must provide something that is desired and thus valuable.

Greed is only irrational when it comes at the expense of others which is generally limited to looting, fraud and so forth. Otherwise, you are only making the pie of wealth greater for everyone.
+1, well put.
6083  Other / Politics & Society / Re: Human Augmentation on: August 17, 2011, 07:19:18 PM
I don't see why not... if someone wants to make themselves a robot or a superhuman, that's up to them.
6084  Economy / Lending / Re: loan agreement on: August 17, 2011, 07:18:16 PM
Quote
Last Active:   August 12, 2011, 09:49:21 am

Good luck.  Wink
6085  Bitcoin / Bitcoin Discussion / Re: Distributed wallets/bank accounts? on: August 17, 2011, 07:02:08 PM
Just a high level idea but...

Would it be possible to create a distributed system of wallets such that the wallet is created, simultaneously encrypted and then distributed on a system of servers similar to the way Bitcoin now works where an encrypted file is kept on various servers all over the world. And to connect to your wallet you merely need to connect to one of these servers, deposit some money and create a password and from then on that account is your own. Those that run the server could get a fixed interest amount for hosting your account in a similar fashion as the way miners are paid.

Then during a transaction you could just connect to the account network and authorize the transaction.

I have no idea but just figured I would throw that out there.
I've suggested the same thing in the past, and we came to the conclusion that yes, it would be possible, but nothing like it exists yet, so it would be difficult, time-consuming, and potentially expensive to execute.
6086  Bitcoin / Bitcoin Discussion / Re: Bitcoin Conference 2011 NYC on: August 17, 2011, 07:01:08 PM
All,
  I'm proud to announce that the mobile conference app is now available.  You can access the app (iOS/Android Compatible) by going to: bitcon.mobi  If you are on an Apple iOS device, you can add it to the home screen and run it as a full-screen webapp.  I will update the schedule per the latest one published momentarily.  If you have pictures of the event, please e-mail them to photos@bitcon.mobi, or to the guys at OnlyOneTV and they will be added to the Pictures feed in the app. (Photos are screened before posting, so no, your porn won't make it in the app)

Current Features Include:
  - Interactive conference schedule with maps/phone integration (still in the process of updating with the latest info)
  - List of speakers (still in the process of adding the new ones)
  - Twitter Feed (Hashtag is #bitcon11)
  - Photo Feed
  - YouTube Feed
  - Location Map
  - Sponsor List

So whether or not you're going, stay up to date with the latest goings on using the bitcon.mobi app.

Unless it's really good.
Excellent!  Just "installed" it.  Smiley
6087  Bitcoin / Bitcoin Discussion / Re: Bitcoin high inflation environment - Doesn't need greedy miners on: August 17, 2011, 06:58:38 PM
The truth is this. At a high inflation environment, if the price is lets say 5 dollars (instead of 10 dollars), and it goes up from there in small steps (instead of speculators speculating up the price with high fluctuation). The money going in to the Bitcoin Economy will stay there at a much higher grade, because you don't have greedy miners that hit the exchanges as soon they have mined 0.1 BTC and order a withdrawal. You can see it ass good money/ "long term money" and bad money/"short term money". Right now Bitcoin is attracting Bad money.
That sounds like more of a problem with speculators than miners.

Either way, they shouldn't (and won't ever) be limited.
6088  Bitcoin / Development & Technical Discussion / Re: Fake Bitcoins? on: August 17, 2011, 05:59:14 PM
+1 for vector76's hypothesis from me as well.

This seems a lot more likely than my double block mining hypothesis.  This would also be harder to protect against.

Anyone have ideas about how to stop this sort of attack?
Have your node connected to LOTS of other nodes.  Someone correct me if I am wrong.
6089  Alternate cryptocurrencies / Altcoin Discussion / Re: A Better Coin on: August 17, 2011, 05:42:48 PM
ABCOIN
- Demurrage rate of 0.285% / year (the estimated number of lost coins each year as a percentage of total coins in circulation)
- Inflation rate of 4% / year (the estimated worldwide GDP growth each year - note that, because of GDP growth, the purchasing power of the coins should stay the same despite the inflation of actual money supply)
- Block rewards start at 1, and increase linearly to a rate of 500,000/block over the next 10 years
- Block reward then inflates at a rate of 4% / year.  So the next year, it would be 520,000, etc.
- Block reward will be paid partially in demurrage, partially in newly minted coins.  Eventually demurraged coins would exceed the block reward (when the number of outstanding coins reached around 14T), and no new coins would be necessary - the block rewards could be paid entirely from demurraged coins.

Again, of course, this is all planning for world domination of ABCOIN, but we should dream big, should we not?  Smiley

- I'm still unsure about the difference between adding a demurrage 0.285% or just using an inflation of 4.285%. I'm guilty of skipping some of the discussion though, I'll have to take a better look.
- What about the evidence that the growth rate actually grows exponentially on a large scale of time (probably due technological progress and population growth)? I'm of the opinion that this trend will continue rather than slow down so our model could be obsolete in just a few decades.
- If we start the reward from 1 and increase it linearly to 500k in 10 years (it would have to increase by almost 1 coin every block) then no merchant will ever want to accept the currency for goods and services because the initial inflation will be way too high. I propose we have a minimum block reward instead, say 1000. If nSubsidy is simply MoneySupply * rate then the reward remains 1000 always until nSubsidy becomes greater in about 10 year or more depending on the rate. In this way (supply) inflation from year 1 to 2 would be 100%, from 2 to 3 50%, then 33,34%, 25%, etc. until we reach our target inflation.
- Hmmm... now you've got me all confused about the same thing.  Would putting the lost coin rate into inflation increase prices of goods over time?  I believe the argument for demurrage is that it would help keep prices stable, even though a person might lose coins over time.  So instead of a $1 burger being $5 30 years down the road, it would still be $1, but you would only have $0.20 left after 30 years.  And that would be a very extreme example with a much higher demurrage rate than what we are talking about here, but you get the idea.

- Not much we can do about change in growth rate.  It's completely unpredictable.  You argue that the rate will grow due to technological advances, and I might argue that it will shrink due to limited resources.  This will introduce some amount of mild inflation or deflation, depending on whether growth rate increases or decreases.  Without including some sort of manipulatable index, there's no way to account for this potential change, so it must be accepted as a caveat of the currency.

- The initial 10 years (or whatever period of time is chosen) would be the "adoption period".  I would guess that this would involve lots of mining and very little actual merchant transactions.  The purpose of this period would be to spread coins to anyone who wanted them.  There should be no "early adopter" problem, where a single individual ends up with more than 1% of the currency.  We could have that time period only be 1 year, or increase it to 20, depending on whatever is deemed appropriate before the project is started.  Even after the block reward reaches maturity and only inflates by 4%/year, the actual inflation rate of the currency will be very high for several more years, as the new block reward/year will be much higher than the number of coins in circulation.

The problem with starting out with a minimum block reward, as you have suggested, is the early adopter problem.  It could easily end up with a single person holding 1% or more of the currency if enough people don't jump the gun and get onboard with mining with a constant block reward.  That's why there needs to be a "ramp up" to the ending block reward.  Now maybe 10 years is a bit extreme for that ramp up, so the actual amount of time to "ramp up" should be considered.

Okay, I'll leave you to work on your thread then. No gifted and suitably trained individuals needed here.
Aww, don't be like that.  I am enjoying your inputs!
6090  Alternate cryptocurrencies / Altcoin Discussion / Re: A Better Coin on: August 17, 2011, 05:22:33 PM

If you agree that volatility is a temporary hurdle, then do you believe that it's clear at this point that it will not be overcome by Bitcoin, and now requires a new attempt?
Yes, I am sure it is a temporary hurdle.  Bitcoin has many temporary hurdles.

The temporary hurdles I am most worried about are: a) wallet security b) price volatility c) merchant adoption.
I am also worried about one long-run hurdle: d) maintaining blockchain security once transaction fees stop

I don't know whether bitcoin will overcome these hurdles or not. However, I do believe that more promising solutions exist.
I don't believe it makes sense to wait for bitcoin to fail before pursuing promising solutions in an alternate chain. At worst it will be a learning experience.

My worry is that splitting the user base between two (or more) separate block chains could be enough to doom both to failure, since this would make the price volatility hurdle that much harder to overcome.  This is one reason why I proposed in post #61 to roll out any new ones via a "distributed central bank", so that it both benefits from and reinforces Bitcoin, while at the same time competing for its users.

Does this worry you as well?
Yes, this worries me.  I think cunicula brought up some good points in response though.  I suppose I look at it this way as well:  Since Bitcoin is already established, if a better coin is created, it will be adopted more quickly than Bitcoin and overtake Bitcoin as the top digital currency.  If the better coin is actually a worse coin than Bitcoin, then it will never come close to reaching the same adoption levels as Bitcoin, and Bitcoin will continue on.  I think there are too many people interested in digital currencies for them to both fail.

@JohnDoe and SgtSpike
You can't have stable prices just by adding a constant inflation (exponential growth of the monetary base) according to your expected growth in GDP. Also, will we have dQ = 4% after, for example, peak oil?

Anyway, you are only accounting for dQ there. What about dV? You can't control it directly (as you can do with M).
With demurrage V should be higher and more constant, but still not controlled.
You can't have stable prices if you don't have an input of dP (which is much easier than knowing dQ).

If your concern is small deflation (caused by growth), demurrage partially solves the problem by lowering interest rates.

jtimon, if the global GDP grows by an average of 4% per year, and the money supply stays the same, what do you suppose would happen?  Well, you'd have 4% deflation every year.  In order to counter that, you must increase the money supply by 4%.

Of course it's not going to be completely stable - I already said that in my previous post.  But the goal is to make it as stable as possible without having changable numbers.  In that case, 4% inflation (or whatever the actual weighted average ends up being) is the best estimate we can make to ensure as stable prices as possible.  No, it won't be exact, and no, prices won't be perfectly stable.  But this method gets us as close as possible to stable prices without having variables introduced into the equation that can be falsified and manipulated.

There might be a drop in global GDP growth as we reach the maximums of resource consumption (in fact, I am sure there will be), but there is no way to know when or to what extent this will happen, so we shouldn't attempt to account for it.  The best we can do is extrapolate historical GDP growth into the future.

Demurrage wouldn't solve the problem of deflation.  There's still the issue of less money available per transaction due to GDP growth.
6091  Alternate cryptocurrencies / Altcoin Discussion / Re: A Better Coin on: August 17, 2011, 06:35:49 AM
So what about a new proposal then?  It's a merger, if you will, of the two mainly discussed methods in this thread.  Mild inflation + demurraging.

A currency that demurrages to help make up for lost coins (thus avoiding deflation due to lost coins), but also has built-in inflation at the rate of GDP growth (thus avoiding deflation due to an increase in GDP or money velocity with the same money supply).  The inflation rate would be a single percentage and unchangable number, and would be calculated from the weighted average GDP growth for the past 200 years worldwide.  While it wouldn't be a perfect match for future GDP, it is probably the best we could do to ensure as-close-to-possible stable purchasing power with using a number that no one could muck with.

Ideally, the demurraging would equal the number of lost coins, and the inflation would equal the worldwide growth in GDP throughout the coming years.

Also, I would still include the slowly-increasing block reward rate to ensure that anyone who wants to adopt it can do so without too much of a "late adoption" penalty, and to ensure that no single person ends up with too much of the currency.

So, as a bullet-pointed proposal, with some estimated numbers, it would be something like this...

ABCOIN
- Demurrage rate of 0.285% / year (the estimated number of lost coins each year as a percentage of total coins in circulation)
- Inflation rate of 4% / year (the estimated worldwide GDP growth each year - note that, because of GDP growth, the purchasing power of the coins should stay the same despite the inflation of actual money supply)
- Block rewards start at 1, and increase linearly to a rate of 500,000/block over the next 10 years
- Block reward then inflates at a rate of 4% / year.  So the next year, it would be 520,000, etc.
- Block reward will be paid partially in demurrage, partially in newly minted coins.  Eventually demurraged coins would exceed the block reward (when the number of outstanding coins reached around 14T), and no new coins would be necessary - the block rewards could be paid entirely from demurraged coins.

Again, of course, this is all planning for world domination of ABCOIN, but we should dream big, should we not?  Smiley
6092  Other / Beginners & Help / Re: A trick for long passwords in Linux on: August 16, 2011, 11:57:04 PM
That trick is ok, but your easy password should not be a dictionary word. Dictionary words, specially english words are very well knowed.
c2e055acd7ea39b9762acfa672a74136

GO!
EDIT:  Lol, I googled it and the first result was correct.  Point taken.  Wink

Good points all around. My method assumes no one knows you are encoding a simple password. And yes, it would be better to use a non-word. Then an attacker must go the brut force route. The Md5 is long and complex enough to avoid being in the "low hanging fruit" category.

The main advantage is ease of use and relatively strong protection using an easy to remember PW. With a little creativity you can go further. Suppose I used the Md5 result string to hash it again?


It's still lowercase az09 of the same length.

Run a SHA512 string through base64 or something, or even gzip it and use that as a completely untypable password
I suppose it depends what sort of item/object/etc you are securing.  Not everything needs to be fort knox...
6093  Bitcoin / Development & Technical Discussion / Re: [BUG] Possible Double Spend on: August 16, 2011, 11:06:28 PM
I tried to find the same thing, but it's a very convoluted piece of code.  I don't even remember where it was in the github, but even when I did see it, I didn't really fully understand what was happening or how I could determine when I would pay a fee and when I would not.

Anyway, maybe someone else will chime in with the dozens of lines of code that determine the fee so you can take a look for yourself.
6094  Other / Beginners & Help / Re: A trick for long passwords in Linux on: August 16, 2011, 11:04:00 PM

BUT, that assumes that the password hacker knows that he is using an md5 hash for his password.

[...]

Basically, it's very secure (IMO), as long as you don't announce to the world that you're using it.

Such an approach is known as Security through obscurity and not very recommended.
That's like saying your password isn't secure if you post it on a forum.  Roll Eyes  I HIGHLY doubt any hackers are seriously going to add MD5 hashes (or other hashes) of dictionary words to their "check if this is their password" list, much less an even longer list of all of the typical dictionary items that they probably use to check password lists, much less an even longer list of all of those typical dictionary items that they use in all known hashed forms.  I'd give far better chances to me forgetting my own password because it is too complex than a hacker finding out what it is.

I mean, would you go to the MtGox password list and attempt to find someone who used an MD5 hash of a dictionary word as their password (which would have subsequently been stored as md5(md5(word)))?  Probably not.  You'd probably start with dictionary words, then go with dictionary words + numbers, then go with dictionary words + dictionary words, etc.  There's going to be a lot better chances of going through a lot of other lists (heck, even random alphanumeric characters) of finding the correct password than there would be of going through an MD5 hash list.

Now I'm not saying one should use a simple MD5-hashed dictionary word as their password, but perhaps whatever is the most complicated "memorable" password with an MD5 hash would be best.  Something like Tails4Thew1n, in MD5 hash form, and no dictionary attack is going to get it.

Call it security through obscurity all you want, but it would work, and it would work a heck of a lot better than people using (and losing) their 64 random character combinations.
6095  Bitcoin / Development & Technical Discussion / Re: [BUG] Possible Double Spend on: August 16, 2011, 10:50:13 PM
The newness?  I didn't realize the client put a transaction fee on new coins.

I thought it wouldn't even let you send coins until they had 6 confirms (12 for fresh minted coins).
Well, it's a complex formula.  It won't always put a transaction fee on new coins, but it often will.  If you send a large amount, that helps to avoid a fee.
6096  Alternate cryptocurrencies / Altcoin Discussion / Re: A Better Coin on: August 16, 2011, 10:45:56 PM
Also, how would a demurraging currency account for growth in GDP?  Wouldn't price deflation hit if more people are after the same number of coins?
6097  Alternate cryptocurrencies / Altcoin Discussion / Re: A Better Coin on: August 16, 2011, 10:45:06 PM
Good point with the pools.

Demurrage destruction takes place in all outputs (accounts to simplify) whether the private key to access those funds is lost or not.
So the generation rate is constant [(target_base * demurrage) / 52560 = reward]. Say we have 3% annual demurrage then

(21000000 * 0.03) / 52560 = 11.9863014

The recipient can verify how much he received, but once the transaction is in the chain, he's taking the losses from the demurrage.
The payer must send more coins than he wants the recipient to receive, because in the time between he sends the tx and it gets into the block, demurrage also applies.
More technical details here:

https://bitcointalk.org/index.php?topic=36190.0
https://bitcointalk.org/index.php?topic=35705
So the demurrage wouldn't necessarily be recorded in each block (else you'd have millions of transactions per block), but it could be easily calculated to show an accurate wallet balance at any given time.  Makes sense.

Lost coins would still take a long time to recover though... I mean, 0.97^X=0.000000004 where X = what?  634 years before a lost coin would completely recovered if rounded out to 8 decimals.  Still, it's better than not recovering them at all, and most of it would be recovered early on.

Sounds like a good idea.  I like it.  I think I like it better than my own idea, but will have to give it some more thought.  There's definitely some psychological battles to acceptance for such a currency...
6098  Bitcoin / Development & Technical Discussion / Re: [BUG] Possible Double Spend on: August 16, 2011, 10:33:36 PM
I think I found a situation where the Bitcoin Client will double spend.

BACKGROUND:
I sent all my Bitcoins to myself so that I would stop having to pay the 0.005 BTC transaction fee (my money was in very small amounts throughout several addresses).  By consolidating all my money into one address I would not have to pay the fee because my transaction wouldn't be over the size limit.

REPRODUCE:
Send all your coins to several addresses until your forced to pay the 0.005 transaction fee for any transaction.
Send all your coins to a new address in the same client. (Paying the fee)
Before the transaction has 6 confirms (it only has 2 for me) send money to a new address.
It should ask you to pay a transaction fee.

MY UNDERSTANDING:
I believe that this is because it is trying to send money from the old addresses because the new address has less than 6 confirmations.  I think it still see the money in your wallet balance and therefore it is willing to overlook the fact that you have already sent that money.

Of course I could be entirely wrong, but I would like it if someone could look into it a bit more.  At least to give me an explanation of why it happens if I am wrong.
I don't see a double spend here.  What you've done is....

Send coins from A to B
Send coins from B to C (tx fee of 0.005)
Send coins from C to D (tx fee of 0.005)

The reason it requests a transaction fee is because of the "newness" of the coins.
6099  Alternate cryptocurrencies / Altcoin Discussion / Re: A Better Coin on: August 16, 2011, 10:21:25 PM
0.285% was the number of coins lost in the last year (around 20k) vs the number of coins in existence (around 7M).  It's not an exact number, and it would be difficult to say that it would be an accurate extrapolation to be distributed across a large number of people, but at the moment, it's the best number I have to work with.

Again, with trying to tie the number of coins to a CPI, or similar metric, you'll have the problem of people attempting to manipulate said metric to their own favor.  If it's going to be tied to anything, it must be indisputable, easily measured, and automatically calculated.

The metric should be inside the system from external exchange prices.
Miners are supposed to reject blocks with wrong reports about external exchange prices, but yes, those are my fears about stable coins.
Probably more orphan blocks would be a problem for that system too.

That's why I stick with freicoin for now. The demurrage rate can be set exactly and will eventually be equal to the reward, letting you have a stable monetary base. You don't have to worry about lost coins because they will get destroyed.
Price deflation concerns are diminished too, because demurrage (unlike inflation) lowers interest rates (by discouraging hoarding while not inflating other capitals value).
Relying on outside metrics would become even more of a problem with the mining pools we have now.  If 3 of the major pools were convinced to alter the actual metrics, they could control the blockchain and force those metrics on everyone else.  There's the argument that people would switch pools, but not everyone would pay attention or care about it.  It would just get messy and cause a lot of headaches.

How would lost coins be destroyed with demurrage though?  Would the system calculate that any coins beyond a particular age (where age = the point at which the amount of demurrage would equal 100%) would be automatically destroyed by such a system?  Wouldn't that lead to a particularly unstable reward rate?  Some points, you might suddenly get 9000 coins because someone lost them a long time ago.  It'd be like a lottery system instead of a steady payout a miner could count on...

Also, how would a merchant know what the actual payment is, if the demurrage is coming out of the payment?  What if the buyer uses coins that would be 95% demurrage?  Or would the buyer have to send 2000% as many coins in order to pay said merchant?

It's an interesting idea...
6100  Alternate cryptocurrencies / Altcoin Discussion / Re: A Better Coin on: August 16, 2011, 09:13:53 PM
@SgtSpike
I guess 0.285% (no matter the size of the economy) should be enough. Where did you get that number from?

Then the only way to maintain the purchasing power of the currency is for the velocity to increase by 10%. That's doable for some time but obviously unsustainable as the velocity can't be increased forever. Not to mention that deflation would encourage a reduction in the velocity instead as people shift towards saving.

My proposal is that price stability would be more likely if we try to fix %ΔM to something like 8%~10%. Of course, changes in velocity and GDP growth can't be control or predicted but I believe this model would be more suitable to achieve the behavior that we want.

%ΔV is highly unpredictable, but it would be closer to zero (more stable) if the currency had demurrage (also V would be higher).
But then, you still have to set %ΔM as a function of %ΔQ (or %ΔP as a measure).
There's a proposal named stablecoin for that. I think it could be better implemented with demurrage but I still have many doubts about if the potential problems for the network derived from the %ΔP input.
Since you're creating coins (and destroying) even when ΔP = 0, you also solve the "reward miners forever" problem with that solution.
In that thread most people prefer destructive tx fees instead demurrage, but that makes V even more unstable.

0.285% was the number of coins lost in the last year (around 20k) vs the number of coins in existence (around 7M).  It's not an exact number, and it would be difficult to say that it would be an accurate extrapolation to be distributed across a large number of people, but at the moment, it's the best number I have to work with.

Again, with trying to tie the number of coins to a CPI, or similar metric, you'll have the problem of people attempting to manipulate said metric to their own favor.  If it's going to be tied to anything, it must be indisputable, easily measured, and automatically calculated.
Pages: « 1 ... 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 [305] 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 ... 405 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!