Bitcoin Forum
May 25, 2024, 05:09:18 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 [55] 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 ... 195 »
1081  Bitcoin / Bitcoin Discussion / Re: Concerns about the Bitcoin Foundation (email inside) on: April 18, 2013, 01:33:38 AM
This shit has been gone over and over and over on the forums.  Atlas used to pull this same crap.  He'd pop up under yet another sock puppet account and ask "questions" about the foundation.  I put questions in quotes because he damn well knew the answers from the previous dozen times he asked.

At this point, I feel pretty safe calling this entire thread a troll.  If I'm wrong about that, and the original post was from someone genuinely asking for information, then I apologize for calling him a troll, but I'll instead call him a moron (for reasons that I hope would be obvious once the troll option has been removed).

Why would you call me a moron for asking if the foundation will respect the 21 million limit, and not allow for government intervention in the blockchain?
I'd love to hear your reasoning behind that.  If that info would be shown on the website, or they would have replied to my email, asking them exactly that, maybe (but probably not).

As has been discussed in extensive detail in the thousands of other posts on this subject, the opinion of the foundation, to whatever extent that an organization can be said to have opinions, doesn't matter even a tiny little bit in regards to these two things.  The foundation has exactly the same amount of authority to make changes to the system that you have, none at all.

I'm really not kidding about the thousands of posts on this topic.  Did you intentionally avoid finding them (troll), or did you look, but fail (moron) ?
1082  Bitcoin / Bitcoin Discussion / Re: Concerns about the Bitcoin Foundation (email inside) on: April 18, 2013, 12:31:40 AM
I can't at all see how the questions of the OP was 'silly'. He has his views, and he doesn't want to put his money in the pocket of someone not sharing his views, simple as that. I don't see how anyone has any problem with that. As it's said, there are no silly questions, only silly answers, also who's to randomly decide what are silly questions or not, I guess the definition of that would vary a lot. Heck, if I wanted to be difficult, I could say that all questions on this forum are silly, as probably 80% of the questions asked could probably be solved if someone just bothered to google for an hour and read various information posted online..

This shit has been gone over and over and over on the forums.  Atlas used to pull this same crap.  He'd pop up under yet another sock puppet account and ask "questions" about the foundation.  I put questions in quotes because he damn well knew the answers from the previous dozen times he asked.

At this point, I feel pretty safe calling this entire thread a troll.  If I'm wrong about that, and the original post was from someone genuinely asking for information, then I apologize for calling him a troll, but I'll instead call him a moron (for reasons that I hope would be obvious once the troll option has been removed).
1083  Economy / Economics / Re: Investment Plan on: April 17, 2013, 10:40:42 PM
If you have any sort of investment plan that involves metals and stocks, you need to understand this chart, and follow it closely.

http://investmenttools.com/images/wfut/metals/dow_gold.gif
1084  Economy / Economics / Re: what keeps the price down? on: April 17, 2013, 10:31:39 PM
This thread, and the thousands like it, is garbage.

You'd get better information by turning on a random financial news station and pretending that everything they were saying was about bitcoin.  Bitcoin is traded on a bunch of open markets, meaning that the "price" is set by the crowd.  Some people in the crowd will have reasons, maybe even good reasons, but the crowd itself does not.  It just is.  Trying to figure out the crowd by looking at a few members is counterproductive.  Not only will you fail to learn anything, but you will typically get a false sense of understanding.

Bitcoin is volatile because it is small.  A few million dollars can drive the instant price way up, and a few million bitcoins can drive it way down.  Until it stops being small, no other reason is necessary or meaningful.  If bitcoin is trading in a range between 50 million dollars and 250 million dollars per 1 BTC over the course of a month, it might be worth looking at.  Until then, stop looking for scapegoats and reasons.  There are none of either to be found.
1085  Bitcoin / Development & Technical Discussion / Re: How to run 2 bitcoin-qts? on: April 17, 2013, 12:17:00 AM
Every node that runs has different block files.  If you really need to save space, there are ways to partially synchronize them, at least with the old BDB index.  I haven't played with 0.8+ enough to know if the same trick would work there or not.
1086  Bitcoin / Development & Technical Discussion / Re: How to run 2 bitcoin-qts? on: April 16, 2013, 03:13:26 PM
A VM inside the machine Tongue
Srsly, Idk, but at least having a VM would work...

And I'm wondering: y u want 2 clients open?

I run two nodes on one machine.  One node is a hub and accepts a ton of incoming connections from around the world.  The other node is only connected to that hub, and has a wallet.

I mostly did it because I have a cron job that detaches the wallet node and copies the block files out for distribution to my RAMdisk mining nodes, to speed their reboots.  I wanted to keep a well connected node running, despite shutting down the client every day, so I've been running two for quite a while now.  Turns out that there are nice privacy and security benefits from running them split like this too.

And grue has it exactly right, as usual.  You need two sets of data directories, two configuration files, and two sets of 2 ports.  You can even talk to both nodes using the bitcoind command line by specifying -conf= along with your commands.
1087  Bitcoin / Development & Technical Discussion / Re: Multi-signature transactions on: April 16, 2013, 03:05:23 PM
The reference client has supported multisig for a while now.

Search for the rawtransaction API for more information.  See this thread and especially, Gavin's gist.

Here is some PHP that takes an array of keys ($keys) and a number of keys required to spend ($nReq) and creates a P2SH multisig address and redeemScript.  This isn't necessary, since the API can do the same task.  This is just for those times when you want totally offline generation.  Note that the hashing steps after $rs is completed are exactly the same as the hashing done to normal addresses, just with a different magic number.  Also, the sorting step is not necessary, I just do it to make it easier to recover in case the metadata is lost and I'm left with just a bunch of keys.

Code:
<?php

function createmultisig($nReq,$keys,$sortkeys=TRUE){
 if(
$sortkeys)sort($keys,SORT_STRING);
 if(
$nReq<OR $nReq>16 OR $nReq>count($keys))return FALSE;
 
$rs=chr(0x50+$nReq);
 while(list(
$key,$val)=each($keys)){
  
$bpk=hex2bin($val);
  
$rs.=chr(strlen($bpk)).$bpk;
 }
 
$rs.=chr(0x50+count($keys));
 
$rs.=chr(0xae);

 
$h=hash("sha256",$rs,TRUE);
 
$h2=hash("ripemd160",$h,TRUE);
 
$h3="\x05".$h2;
 
$h4=hash("sha256",$h3,TRUE);
 
$h5=hash("sha256",$h4,TRUE);
 
$chk=substr($h5,0,4);
 
$addr_bin=$h3.$chk;
 
$addr=encodeBase58($addr_bin);
 return array(
"redeemScript"=>bin2hex($rs),"address"=>$addr);
}
?>

1088  Economy / Economics / Re: = Grand Unified Solution to Lost Coins, Hoarding, Deflation, Speculation = on: April 15, 2013, 10:35:48 PM
This is a common claim that looters like to make to justify their theft.

It turns out to be exactly 180 degrees from truth.  The reality is that savers are doing a service for the market, not the other way around.  By deferring consumption, you are allowing the market to invest the resources that you would have consumed in the construction of new productive assets.  Growing the productive base is a good thing, and should be rewarded.

Saving is not the same as INVESTING, saving is simply withdrawing currency from circulation and dose not result in any increase in future production, in fact all evidence points to a reduction in future production when this is done.  An investment is a form of consumption, capital goods are purchased, buildings constructed etc, this adds to the stock of capitol.  On the other-hand saving simply results in an unconsumed surplus of goods (generally consumer goods) and this reduces the returns of those that produced them causing them to lower production, reduce labor costs and scrap excess capital that can't be productive.  Thus some of the collective stock of capitol is destroyed needlessly, years later this must all be rebuilt to accommodate the new consumption, the wasted capitol if it had been utilized would have lead to an even larger production in the future, this is why boom-and-bust is bad.

Yes, thank you.  What was missing from these forums was yet one more person parroting the stock Keynesian party line.  You even share the perversely keynesian habit of confusing money with wealth in one sentence, and understanding them as distinct things in the next.

I don't point out your obvious Keynesianness as an ad hominem, but rather to simplify the refutation.  The school of economic thought that you follow is not taken as gospel here.  Merely repeating what you've found in your textbooks will not win you many arguments here.

At this time, I only wish to address two things specifically.

When you save, you are deferring consumption.  You are holding the the token representation of wealth, rather than the wealth itself.  The wealth itself is then free to go where the price signals tell it to go, whether to someone else's consumption, or to capital formation depending on the overall market.

Boom and bust is indeed bad, or at least sub-optimal.  However, it is not caused by savings, it is caused by meddling in the price signals.  Keynesians tend to forget that everything they preach involves suppressing or enhancing price signals, making it impossible for the market to provide correct information.
1089  Economy / Economics / Re: = Grand Unified Solution to Lost Coins, Hoarding, Deflation, Speculation = on: April 15, 2013, 11:42:16 AM
Now let me address another point that opponents of demurrage often raise.  The desire to store value without loss, they point to this desire as a justification for a money system that will allow savings without cost (like Gold or BTC).  But they rarely ask how this is done in a money system when the 'value' of money is all out their in the real world in the goods and services that the money is competing for.  When they do it usually consists of "well I did not spend my income, thus I consumed less now, entitling me to consume more later".  A bit deeper but your now fully dependent on the marketplace to due two things, first it needs to accommodate your non-consumption (you basically reduced money supply) and then it needs to accommodate your increased consumption later in which you reintroduce your money (expanding money supply).  So the marketplace is doing you a service when you use money in this way, and what are you paying the marketplace for this service?

This is a common claim that looters like to make to justify their theft.

It turns out to be exactly 180 degrees from truth.  The reality is that savers are doing a service for the market, not the other way around.  By deferring consumption, you are allowing the market to invest the resources that you would have consumed in the construction of new productive assets.  Growing the productive base is a good thing, and should be rewarded.
1090  Economy / Speculation / Re: "There can be only 21,000,000 bitcoins" is myth => How to secure the blockchain? on: April 14, 2013, 04:41:02 PM

1. Fractional Reserve Banking. For example, MtGox, they do FRB. (I'm wrong? They don't do it? C'mon, even small kids know that MtGox loves FRB.)


credible reports surfaced that ppl could sell more btc than they had at gox, and gox would not give them an error or refuse the order.


that's NAKED SHORT SALE at Mt. Gox!

Yeah, it would be.  Except that when that order comes up for execution, it gets truncated to the currently available balance.  Also, it hasn't been that way for a long time; now the truncation happens when the order get switched from pending to active.
1091  Bitcoin / Bitcoin Discussion / Re: Suggestion: Payment Return Addresses on: April 13, 2013, 04:14:53 AM
Wow.  37 month thread necro.  New record?
1092  Economy / Speculation / Re: 2013 survivors club on: April 12, 2013, 11:33:14 AM
When we passed $75 for the first time, I was expecting a correction down to ~$50, so I sold a few coins.  When we bounced off of $260, I sold a few more for $250.  The total between the two was about 10% of my holdings at the time (after paying for some Avalons).

I have a standing buy order between $50 and $60.  If I see a solid turnaround towards higher prices before we hit my goal, I'll buy for higher if I need to.

When I first learned about bitcoin nearly 2 years ago, I thought it was cool and had potential.  For the last year or so, I've felt pretty strongly that bitcoin was the future of money.  For the last month or so, I've thought that the rest of the world was coming to that conclusion as well.  This crash did nothing to change my long term views.  From what I'm seeing in the press and from people that I talk to, bitcoin is still gaining acceptance, the crash did nothing to slow that down.

I don't consider myself to be a particularly skilled trader (notice that 50% of my recent trades were unprofitable), but I am occasionally willing to risk a small portion of my precious bitcoins when I feel like I can acquire more in the short term.

My only regret at the moment is that I don't have the time to contribute more work to the software.
1093  Bitcoin / Mining / Re: Network Hashrate on: April 12, 2013, 01:17:03 AM
The network hash rate is not measured, it is estimated.  These graphs are showing the actual (unknown) hashrate + random walk noise.  Don't take any graph with a granularity finer than a month or so to be meaningful.
1094  Economy / Economics / Re: Bitcoin facts on: April 11, 2013, 02:04:35 PM
Fact: Only the Satoshie cartel know how many bitcoins they have pre-mined before going public. Any number must be assumed.

Fact: Any transaction ever sent, will be forever traceable.

I challenge anyone to prove wrong any of this facts beyond reasonable doubt.

 Huh
1095  Economy / Economics / Re: How, Why and When the Bitcoin Model will Fail on: April 11, 2013, 03:16:26 AM
You know, it really isn't necessary to respond to every troll that rehashes these topics.  If the original poster is too lazy to search for the thousands of threads that cover these topics in gruesome detail, why do you feel like you need to retype it all for him?
1096  Bitcoin / Bitcoin Discussion / Re: these centralised exhcanges work really well with the concept of Bitcoin on: April 11, 2013, 01:52:43 AM
Bitcoin is decentralized in the sense that no one has the authority to make people use different exchanges.  It is also decentralized in the sense that no one is stopping you from making your own, if you want to.
1097  Bitcoin / Development & Technical Discussion / Re: Let's Embrace BTC Trusted Timestamping on: April 10, 2013, 05:44:24 PM
You can pretty much lock any file in a single point in time by adding somewhere in it:  "The hash of bitcoin block number [most recent block] is [hash], and the sha256 hash of this document, in the form you now have it, [presumably a PDF or something], will provide a raw hex private key for an address which I will send [X.XXXX] bitcoins to, and shortly thereafter send them back to the originating sending address.  This document listing the hash of block [most recent block] proves that it was created after that time, and the transaction to the hash of this document itself proves that it was created before that time."  Bam, locked in a single window of time for all eternity.

This won't prove anything. What's preventing me from creating a PDF document with exactly that contents afterwards, describing some old transaction (and back) that I did in the past?

Read carefully.  You are missing a couple of steps.

Sorry, my fault. He's describing how to create a private key out of the document hash, which might work indeed. Although I'm not sure. Any comments on my question?

2b) I'm not sure if it is technically correct to generate a private key from a random SHA-256. Maybe I just have to refresh my knowledge about elliptic curve asymmetric cryprography, but I'm afraid that multiple SHA-256 sums could lead to essentially the same private key, or at least to the same public key, thus reducing the trust you can put into that kind of timestamping.

However, putting the latest bitcoin block hash into the text is a waste of bits. Although it proves that you creates this portion of the document at that time (or later), the rest of the document could have been written years ago. Or maybe you just had it in your head and didn't write it down. Who knows?

So I agree that the upper bound works, but not the lower bound.

Any collection of 256 bits can be a bitcoin private key.  The output from SHA-256 is perfectly suitable.  There is a miniscule chance of creating a weak key with hashing, but you can add a nonce and try again.  You should also play the lottery if that ever comes up.

The catch is, however, that you intend to publish the document at some point, so you can't use the account for storage.  You just transfer in as proof, then transfer out to keep your cash, and then you publish.

My system did almost exactly that, just with an indirection step to minimize the blockchain bloat.  I would take one or more documents, hash them, and then collect those hashes into a new document.  The new document would be hashed, and that hash would become the private key.  A transaction would be sent to the corresponding address, and then back to my wallet, and then the list would be published.  Anyone would be free to download the list of hashes once the money was safely back in a secret key.

Including a recent block hash doesn't help much.  You are quite correct that you can't prove that the rest of the document was created at a certain time, and no timestamping service can do that.  The best it can do is prove that it merely existed at some particular time.
1098  Bitcoin / Development & Technical Discussion / Re: Let's Embrace BTC Trusted Timestamping on: April 10, 2013, 02:44:33 PM
You can pretty much lock any file in a single point in time by adding somewhere in it:  "The hash of bitcoin block number [most recent block] is [hash], and the sha256 hash of this document, in the form you now have it, [presumably a PDF or something], will provide a raw hex private key for an address which I will send [X.XXXX] bitcoins to, and shortly thereafter send them back to the originating sending address.  This document listing the hash of block [most recent block] proves that it was created after that time, and the transaction to the hash of this document itself proves that it was created before that time."  Bam, locked in a single window of time for all eternity.

This won't prove anything. What's preventing me from creating a PDF document with exactly that contents afterwards, describing some old transaction (and back) that I did in the past?

Read carefully.  You are missing a couple of steps.
1099  Economy / Speculation / Re: Convergex group suggesting diversification into Bitcoin on: April 10, 2013, 02:00:20 PM
Other than the limit question, it was a very good interview.  He speaks well, and has a decent grasp of how it works.
1100  Bitcoin / Bitcoin Discussion / Re: Is block-chain compressed? on: April 10, 2013, 01:57:03 PM
bzip2 actually gets around 25-35% compression on the files, at a huge time and CPU cost.

While parts of the data are pathological, other parts are very regular.  You might be able to get somewhat better results by writing a hybrid compressor that skips over the parts that we already know are random.
Pages: « 1 ... 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 [55] 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 ... 195 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!