Bitcoin Forum
April 24, 2014, 11:49:49 PM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: 1 2 3 4 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 ... 190
901  Bitcoin / Bitcoin Discussion / Re: Website to verify bitcoin signatures? on: April 30, 2013, 07:59:45 PM
I just had to check, and it appears that the decoderawtransaction RPC command does not validate the signatures, so making such a thing isn't as simple as just slapping up a bitcoind and a couple lines of PHP.

I think he wants to verify a signed message, ie what bitcoin does with verifymessage. That can be easily put behind a quick script

I didnt think that there are so many interpretations but i meant the functionality where one can sign a message with an address one owns. This way another person can verify that the other person owns that address. For example verifying that an address is bound to a username here in the forum.

Oh, that?  Well, that is certainly easy enough.

Code:
<?php

$rpc_user
="";
$rpc_pass="";
$rpc_port=8332;

require_once(
"jsonRPCClient.php");
$rpc=new jsonRPCClient('http://'.$rpc_user.':'.$rpc_pass.'@localhost:'.$rpc_port.'/');

if(isset(
$_POST['submit'])){
 try{
  echo 
"Address: ".$_POST['address']."<BR>\n";
  echo 
"Signature: ".$_POST['signature']."<BR>\n";
  echo 
"Message: ".$_POST['message']."<BR>\n";
  if(
$rpc->verifymessage($_POST['address'],$_POST['signature'],$_POST['message'])){
   echo 
"Valid.<BR>";
  }else{
   echo 
"Invalid.<BR>";
  }
 }catch(
Exception $e){
  echo 
"Error.\n";
 }
  echo 
"<HR>";
}

echo 
"<HTML><BODY>\n";
echo 
"<FORM method=POST>\n";
echo 
"Address: <INPUT type=text size=40 name=address";
 if(isset(
$_POST['address']))echo " value=\"".$_POST['address']."\"";
echo 
"><BR>\n";
echo 
"Signature: <INPUT type=text size=40 name=signature";
 if(isset(
$_POST['signature']))echo " value=\"".$_POST['signature']."\"";
echo 
"><BR>\n";
echo 
"Message: <TEXTAREA name=message>";
 if(isset(
$_POST['signature']))echo $_POST['message'];
echo 
"</TEXTAREA><BR>\n";
echo 
"<INPUT type=submit name=submit value=\"Verify\">\n";
echo 
"</FORM>\n";
echo 
"</BODY></HTML>\n";
?>

902  Other / Off-topic / Re: What programming languages do you know? on: April 30, 2013, 07:13:48 PM
I'm not aware of any problem that can't be solved with either C, LISP or both.  C is good when you need to think about the machine, LISP is good when you need to think about the problem.

Or, in other words, most of what most computers do most of the time is not what we would normally think of as "computation" except in a very technical sense, and C is a very good language for handling the non-computational tasks involved in, for example, an operating system.  It is also excellent if you need to do bulk computation.

LISP, on the other hand, is great for breaking down complex problems, or doing a bunch of processing.  I am occasionally sad that bitcoin scripts are not very LISP-y.  That has always struck me as another instance of Greenspun in waiting.

In real life, most of the time, I end up using PHP by default.  Since it is mainly a web programming language, it is already connected to a ton of stuff, and since it is based on C, it has access to tons of low level stuff too.  Want a daemon that accepts network socket connections, performs cryptography, talks to a database, and can email you PDFs?  Done and boring.  It is just as much a universal glue as Perl, but way less annoying, and people can actually read it.
903  Bitcoin / Development & Technical Discussion / Re: Entropy during private key generation on: April 30, 2013, 06:49:28 PM
Quote
(12:10:30 AM) gmaxwell: Under certain threat models, like the attacker being on
a common multiuser system with you and being able to monitor 99.9% of the
urandom output, then it's potentially interesting.

For those not following along, /dev/urandom uses a cryptographic pseudo-random number generator when the entropy pool is depleted below the ability to satisfy a request with actual entropy.  CPRNGs are very widely used and very safe.

The weakness that gmaxwell is talking about is that since a CPRNG is deterministic (it is an algorithm that runs on a computer), someone observing a sequence of outputs from it could possibly reconstruct an output that they did not observe.  In practice, this isn't a big deal, because if anyone was in a position to observe the stream, you are already well fucked and they can probably just take your keys directly.

Also, note that he says "potentially interesting".  I'm not current on the literature, but I'm not aware of anyone actually reproducing the missing portion of a stream by using this method.  It is theoretically possible though, and maybe someone has actually done it.  Also, people are aware of the problem and take steps to make it harder.*

A genuine entropy source will provide a stream of bits that have absolutely no relationship to any other bits anywhere in the universe.  Someone watching such a stream go by will not in any way be able to recreate the part of it that you take.

In practice, it comes down to paranoia.  I side with paranoia in theory, but with reality in practice.  As in, I prefer my keys to come from sources as close as possible to actually being genuine entropy sources.  But those suck, so I use RDRAND, EGD, and other sources of high quality pseudo-entropy.  On an offline box, the difference should be negligible.

A weak system produces outputi from outputi-1.  A strong system produces {outputi,statei} from hash(statei-1).  As long as the hash function is cryptographically strong, observing the stream of outputx doesn't give enough information to recreate state or outputy.  Actual cryptographers (which I am not) undoubtedly have schemes even better than this one.
904  Bitcoin / Bitcoin Discussion / Re: A Warning Against Using Taint on: April 30, 2013, 06:20:28 PM
kjj, Steve doesn't need people being exasperated.  He just needs some explanation...

Heh, I had just hoped to point out the contradiction so that he could examine it for himself.  My confusion was rhetorical, rather than actual.

Once you see it for yourself, it becomes obvious that following law is only moral when the law is moral.  From there, you can divide out the middle step and see that on one side you have (moral = moral) and on the other side you have (law = law), with no fundamental connection between the two.  Having laws that are moral is an ideal that we must strive for.

Ghandi and MLK both wrote fairly well on the struggle to make law moral.  Letter from a Birmingham Jail is an excellent read on the topic.
905  Bitcoin / Bitcoin Discussion / Re: Website to verify bitcoin signatures? on: April 30, 2013, 06:06:13 PM
I think he is asking if anyone is running a web service that can accept a hex (or whatever) bitcoin transaction string and indicate if the signature is valid or not.

I'm not aware of any sites that do that.  That doesn't mean there aren't any.

I just had to check, and it appears that the decoderawtransaction RPC command does not validate the signatures, so making such a thing isn't as simple as just slapping up a bitcoind and a couple lines of PHP.
906  Bitcoin / Bitcoin Discussion / Re: A Warning Against Using Taint on: April 30, 2013, 05:38:59 PM
I always thought breaking the law was immoral by definition.

Sure, breaking the old Jim Crow laws was illegal, not immoral.

Huh
907  Bitcoin / Bitcoin Discussion / Re: Can Bitcoin survive a real fork? on: April 30, 2013, 05:36:35 PM
Now and then, I start thinking that you might be confused by the polysemy of "fork".

The software can be "forked" by anyone at any time.  If their "fork" is compatible with bitcoin, then the world has two different clients for the same network.  The popularity of the two softwares will vary depending on how well they meet the needs of the users.  For now, call this #1.

If the "fork" is not compatible with bitcoin, then it is not bitcoin and the world now has two networks, each with their own client.  The popularity of these two networks will vary, depending on how well they meet the needs of their users.

The way these two networks differ depends on a choice made by the developers of the new software.  They can start fresh with a new genesis block and a new chain (#2A), or they can create a moment of divergence, where the blocks prior to that point are valid for both tines, while blocks after that are only valid for one or the other, this would be a chain "fork" (#2B).

#1 is encouraged, in a way, but difficult.
#2A is the standard scamcoin-de-jour model.  Note that no scamcoin has yet managed to develop any significant capital formation.
#2B has not yet been seen, and, as I've previously described, users of the not-bitcoin branch should expect the value of their holdings to evaporate quickly, making it unlikely to ever start.

Your last post seems to suggest that you are concerned about a #1 fork turning into a #2B fork.  It will not happen, because the gravity of bitcoin resides not in the whims of the developers, but in the economic power that has grown up around the network.  By last fall, bitcoin had grown big enough that the economic mass of the system was able to band together to hire a full time programmer, and several other people were making a decent living off of donations for their contributions.  Who knows where we will be by next fall...

Bitcoin the software project can live or die without consequence, but Bitcoin the network is probably self-sustaining and immortal at this point.
908  Bitcoin / Bitcoin Discussion / Re: Can Bitcoin survive a real fork? on: April 30, 2013, 04:55:28 PM
I'm more into question how would situation when there massive loss of connectivity between geographical areas, namely continents be handled?

In case of no-double spends the end result is just incorporating transfers to longer block chain. But if there were double spends or sufficiently long delay that some blocks were spendable it would be real mess...

As global currency bitcoin is rather fragile, depending a lot on cotinuing existence of Internet...

If aliens cut the planet in half, we'll have bigger problems.

Considering the relatively low amount of network traffic needed to move blocks around, that is about the most likely scenario.  No other network severing would be complete enough to cause those problems.
909  Bitcoin / Development & Technical Discussion / Re: How to parse blocks on: April 30, 2013, 04:32:06 PM
I haven't upgraded to 0.8 on my development box yet, so I haven't had a need to peer into the new block files.  Are they the same format as the old ones, just smaller, or did they get changed?
910  Economy / Service Discussion / Re: What happened to block 1551? on: April 30, 2013, 03:42:36 PM
It means that blockchain.info, which is totally not "the blockchain", used a parser that assigned index numbers that have no relation to the sequence in the chain.

Can we get a stick at the top that "blockchain.info != blockchain != bitcoin" ?  I'm getting tired of these threads in here.
911  Economy / Service Discussion / Re: Bitcoin Foundation says my computer is infected? on: April 30, 2013, 03:30:14 PM
Or maybe you should google cloudflare.
912  Bitcoin / Bitcoin Discussion / Re: Bitcoin: some more dark scenarios on: April 30, 2013, 03:28:50 PM
I wish we had a "time out" room where we could stuff people that try to advertise their crappy blogs on these forums.
913  Bitcoin / Hardware / Re: [Avalon Asic] trade-in Thread on: April 30, 2013, 01:47:38 PM
Ditto.  I paid full price for my batch #2 order, and I want my trade-ins to be more units at the discounted #2 dollar price.
914  Bitcoin / Bitcoin Discussion / Re: Canada Taxing Bitcoin Transactions on: April 30, 2013, 01:45:40 PM
Frankly, I don't think bitcoins are practical because you you cannot make change with them though I can see exchanges with one half of a bitcoin in the future. Perhaps bitcoin bytes of .01 are not far off.

Huh
915  Bitcoin / Bitcoin Discussion / Re: Can Bitcoin survive a real fork? on: April 30, 2013, 01:18:48 PM
Wouldn't it have been easier to just read one of the other hundred threads on this topic?

There is no voting.  If a change doesn't get overwhelming support from the community, it doesn't happen, partly for reasons that you mentioned.  Also, the minority chain would be worthless, because any merchants that switch to it will be flooded with people dumping their holdings.  Those purchases would be free, because the people making them don't care about holding coins in that chain, which will cause the value of coins on it to plummet.  This will be particularly severe with changes that go against the monetary policies established in the main chain, like inflation or theft (you call it recycling, but we call it theft).

"If a change doesn't get overwhelming support from the community, it doesn't happen" that sounds like voting to me.

And thanks for elaborating the seriousness of a project fork.

If it is a minor fork, where only 10% of the miners left, their chain will die naturally like how you reasoned.

However, if it is a not so minor fork, such as a 30-40% split, the chance of Bitcoin collapsing will be much higher.  Because you can't be sure who else from the majority camp will betray.  They are equally likely to dump all the coins on the majority camp, and "deflect" to the other one.

If it is a 50-50 split, both will die.

But, it won't be a 50-50 split, at least not in terms that matter.  It won't even be close.

I'm not sure why this is so hard to understand, but the capital that has formed around bitcoin likes the current rules.  The economic power of the system is not going to move from a good system to a shitty one, no matter how many people want to go looting.

The whiny crybabies simply lack the ability to screw with the main chain, but the people staying with bitcoin will be able to utterly destroy the fake one.
916  Bitcoin / Bitcoin Discussion / Re: Can Bitcoin survive a real fork? on: April 30, 2013, 12:23:17 PM
Wouldn't it have been easier to just read one of the other hundred threads on this topic?

There is no voting.  If a change doesn't get overwhelming support from the community, it doesn't happen, partly for reasons that you mentioned.  Also, the minority chain would be worthless, because any merchants that switch to it will be flooded with people dumping their holdings.  Those purchases would be free, because the people making them don't care about holding coins in that chain, which will cause the value of coins on it to plummet.  This will be particularly severe with changes that go against the monetary policies established in the main chain, like inflation or theft (you call it recycling, but we call it theft).
917  Bitcoin / Development & Technical Discussion / Re: Tx fee applied when not expected on: April 29, 2013, 11:31:39 AM
Just out of curiosity, did you use sendtoaddress?
918  Economy / Economics / Re: = Grand Unified Solution to Lost Coins, Hoarding, Deflation, Speculation = on: April 29, 2013, 11:17:43 AM
A business can not get a wash on selling its product at a lower costs for 'more valuable money' because businesses have lots of FIXED COSTS that are on CONTRACT (not least of which is labor, energy, building lease).  Those fixed costs remain in fixed nominal currency units meaning they explode in real costs and eat away all the profit margin that may have existed even if marginal costs to make each widget are at parity with new marginal sale prices of widgets.  So the business is destroyed by deflation and if you had 1 sentila of knowledge about real business you would know this.

What new bullshit is this?

By this logic, inflation (the reality we all live in now) would lead to the destruction of every supplier of the business, the businesses on the other sides of those contracts.  After all, contract prices are fixed and absolute until the end of time and can nether be renegotiated  as needed nor written to compensate for changes in the value of money.

And yet, here we all are.  Derp?
919  Bitcoin / Development & Technical Discussion / Re: Limits to accepting a new longest chain to prevent >50% on: April 29, 2013, 03:16:39 AM
Personally, I am not convinced it is needed.

There was so far... about 2 "emergencies" with the blockchain (that "generate a lot of bitcoins" bug, and the doublespend in the recent fork) none of which were exploited by a real malicious party.

As far as I can tell, many major banks have a less stelar record.

It doesn't seem to me that bitcoin's "the hashiest chain wins" approach is "broken", so maybe we should refrain from "fixing" it.

My issue was always that I didn't like the idea of a hidden chain attack.  If someone has a bunch of hashing power (very unlikely) and generates a chain offline, then publishes it, overturning a huge number of blocks, we pretty much just have to sit and watch.  Of course, we can then intervene after the fact to put it back.

But it seems like a better way would be to devise a scheme where the attacker would be unable to keep their longer chain secret.  That is why I like the exponential difficulty method.  Under ordinary circumstances, and even honest chain forks, the network would operate as usual.  But a high powered attacker is fighting against the clock, and people can look at the number of blocks protecting their transaction, calculate the exponential, and evaluate the risk with something more closely approaching certainty.

The cost is, however, that the notion of correctness gets a little fuzzy.  I still think that it is better to protect the network as a whole, in exchange for individual nodes needing manual intervention during some attacks.  Gmaxwell gives the opposing view, which is widely shared.  It is a really critical part of bitcoin, and won't be tweaked lightly, if ever.
920  Bitcoin / Development & Technical Discussion / Re: Deterministic Wallets and ECDSA on: April 28, 2013, 03:16:29 PM

My understanding is that if either k or dA are NOT truly random an attack could be performed.

Your understanding is wrong. This has nothing to do with the internals of ECDSA, if the keygen that's used to create the privkeys uses pseudorandom bits instead of truly random bits, and there exists an efficient attack in the pseudorandom case, then this implies that the pseudorandom generator (SHA2 in our case) isn't actually pseudorandom. You can see this phrased as a formal proof here: https://bitcointalk.org/index.php?topic=19137.msg771903#msg771903

Where my understanding came from is the Sony playstation hack. My understanding is that since the random number k was repeatedly used the hackers were able to determine dA. My thinking was that if a deterministic algo changes dA in a predictable way, it makes the attack harder, but not impossible (somewhat like a timing attack).

You've given me a great starting point for a better understanding. Thanks!

You are quite correct, if dA was predictable, it would be possible to break.  A lot of effort went into making sure that dA was not predictable.
Pages: 1 2 3 4 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 ... 190
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!