Bitcoin Forum
September 24, 2018, 08:44:33 AM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
  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 97 98 ... 238 »
941  Bitcoin / Development & Technical Discussion / Re: Extracting the Private Key from a TREZOR ... with a 70 $ Oscilloscope on: April 15, 2015, 11:53:55 AM
Going by the pulse widths, it seems like a few cents worth of power filtering caps in the device would have prevented seeing anything exciting on the USB port.  He mentioned removing the screen as well to clean up the signal, so I guess the device isn't even tamper-resistant? It doesn't seem to be going by the Trezor website. Too bad everything has to be made as cheaply as possible.
It isn't connecting to the jtag is easier than the power analysis.

But-- not quite the same, it's conceivable that a sufficiently creative attacker could do basically the same power analysis attack just by recording EMI picked up by the soundcard in the computer or via RF emissions from the device. (It's apparently quite easy to pick up noise from the trezor from across the screen with a radio receiver).  People who've tried this have been frustrated by the extreme amount of noise put off by the screen and power regulators, but sufficiently advanced DSP may overcome it.
942  Other / Off-topic / Re: Public Key Cryptography on: April 13, 2015, 08:16:28 PM
You haven't said what you wanted to do with it.  Bitcoin's system can already accommodate this, just truncate the public key hash further.  ... or did you want encryption? or something else?
943  Bitcoin / Development & Technical Discussion / Re: Kaspersky and INTERPOL Say Blockchain is Vulnerable on: April 11, 2015, 02:48:20 PM
I suggest taking their claims at face value and asking them why they're behaving unethically; make them clarify that what they're doing isn't actually an attack. Smiley
944  Bitcoin / Development & Technical Discussion / Re: Kaspersky and INTERPOL Say Blockchain is Vulnerable on: April 11, 2015, 12:30:08 PM
However, I don't really know how they spawned a notepad from block chain in the victim's computer. Does anyone know the details?
They didn't, and it didn't say they did.

All this is saying is that they can put data inside OP_RETURNS which other malicious software can act on.  This is one of the problems with having non-trivial side-channels for non-bitcoin data. The complaint is mostly hype.

Perhaps the real news should be "Kaspersky says they believe they know a vulnerability in Bitcoin, but they failed to responsibly disclose it to the developers and instead wrote press articles on it".
945  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Stellar on: April 09, 2015, 03:16:51 PM
It's the same security model that Ripple was initially advertised to have, but which didn't actually work in practice. The mechanism and conditions appear to be slightly different, and the requirements actually (somewhat) defined, but the fundamental concern remains.

I pointed out back in 2013 that the result of the OpenCoin Ripple model would either result in centralization or a total failure of consensus; and pushed them to formalize their requirements and to specify a procedure that might actually cause them to be met.  They didn't. When Ripple was deployed the outcome was centralization, and when they repeated the experiment with Stellar the system spontaneously failed.

Just as with ripple back in 2013 the new Stellar proposal is unable to answer the basic questions about how we can know or guarantee anything about the security of the system.  Mazieres and Vitalik describe it as leaving it up to the market and think it will work out. I think it would better be described as leaving security up to chance. And the chances don't look good: leaving it up to the users to ensure a safe and decentralized topology has already failed in practice with a highly similar system _twice_.

I pay attention to these things because I hope to see useful things invented and deployed (for their own sake, and so I can use them in my own project); I also pay attention because I'm concerned about blow-back. _Currently_ people are free to do what they want, here there is tremendous information asymmetry and a host of incentives which are at odds with the public interest (including the fact that the few people like me who can clearly see the problems, have every incentive to say nothing at all; much less enough to be anything but a reed in the wind against a massively funded PR effort); and these efforts raise problems across several domains of law.  The result may well be some crazy efforts to regulate the space as a result, which would harm everyone.
946  Bitcoin / Development & Technical Discussion / Re: Convert private key to address with php or python (no bitcoin core / remote API) on: April 09, 2015, 02:30:29 PM
Is there a trustworthy piece of code or library that can do this?
Trustworthy? Not as far as I am aware of.  There are various pieces of software which have never been subject to peer review, have no tests, have no comments, could not possibly be free of timing sidechannels, etc. Several times people have posted things in this subforum which were outright backdoored (I'd link, but I delete the posts); exploiting the fact that most people don't have the time or patience to audit them. (Of course, all this can also be said for the various cloud services, plus they have a whole host of additional potential weaknesses.)

I wouldn't expect to find one any time soon, writing software in PHP and Python is incompatible with avoiding timing sidechannels or leaving around private key data in memory (not to mention slow); so it's not a first choice for the development of conscientious cryptographic software; and it takes a tremendous amount of work to produce something that deserves confidence.

Signing is even harder, as there have been a large number of implementations out there which were outright broken; using non-cryptographic RNGs that leave the private keys exposed to recovery.  If you didn't require the software be PHP/Python, only callable from it, bitcoin-tx command-line tool in Bitcoin Core can be used for signing, and doesn't require having anything running.
947  Bitcoin / Bitcoin Discussion / Re: Time to bust a myth: Paper wallets are less secure than normal encrypted wallets on: April 06, 2015, 05:28:52 AM
Thanks. You might want to change the ":" to a "." since its easy to misread the title, I loaded this thread all ready to chew you out and disagree with you; only to realize that you were saying the opposite of what I expected from the title. Smiley

"Paper wallets" have been the subject of a bunch of marketing push from a couple different angles. They're fun, some people have a commercial interest in them, they make for good security theater. But seldom do they make for good security.  Ignoring malware the number one risk to people's bitcoins is loss/destruction, and often the paper does particular poor there without special care. (I've now dealt with two people that lost substantial amounts of bitcoins due to paper wallets and water damage!).

An extra data point is that the web services you see are cryptographic crapshoots.

They have random unreviewed crypto code, written by someone who's never done anything like it before or copy-pasta from someplace else that had no review. I've seen a fair amount of stuff that was so broken that you had to have at least four kinds of cluelessness before you would think that the approach taken had any chance of being correct. It's bad enough that you can't ever find intentional backdoors because the honest mistakes are so crazy and so common that an actual backdoor would just hide in the noise.

Not that this problem is unique to the paper wallet space, but it seems to be especially bad there...

The web and JS is already a very hostile environment for writing secure cryptographic code-- JS has a lot of subtle, browser specific, implicit behavior and "action at a distance" that makes it hard to review, review is just not a cultural norm for most web software, the browser execution environment fundamentally cannot provide constant time operation or data leak free operation. ... and basic "key generator" and "signing" code is fairly easy to do (at least if you don't care to do it very well) and a fun little project.  Then these pages are loaded without HTTPS across an untrusted network, through an untrusted CDN from an untrusted server, hosting files for an anonymous and untrusted author.

A bunch of things that would be better described as "Jonny learns to code" are finding themselves in production use with hundreds of thousands of dollars flowing through them, because the end user has no means to judge the integrity of the work or the process that produced it. (And often the authors themselves have no idea how risky things are, or worse-- developer confidence can be inverse related to competence due to the Dunning-Kruger effect).  I'm not sure what to do about this in the ecosystem; it's pretty clear to _me_ when some piece of code or its process has no evidence of meeting even the most basic standards, because I live them every day, but I have almost zero desire to go play gmaxwell-the-destroyer-crusher-of-dreams crapping on other people's project with unsolicited and often unappreciated reviews (it's amazing how hostile some developers are when you point out their stuff is actually broken, not just theoretically ugly), nor do I have the time to do it all myself.
948  Bitcoin / Development & Technical Discussion / Re: Slowing down block propagation on: April 06, 2015, 01:18:50 AM
For what it's worth, I have a woolly idea.  Like most of my ideas though, it's got its security issues and it's pretty firmly in Altcoin territory.

Suppose node operators "advertise" their nodes in the block chain (a maximum of once a month) with a tx that has data attached giving their node's unique IP address.  This would be a good thing anyway as a way to help do node discovery when a client comes back on line.
Been proposed before, we also looked at using it in p2pool but turned out not to need it there.

I think you're over-complicating it. You can just allow miners to disclose an address message in their blocks, could be them, could be some other node they like. It would give another view of the topology of the network, which would be helpful.

A key observation is that the ordinary non-partitioning security requirements mean that you only need one honest peer (but, sadly, privacy requirements mean you would really prefer no dishonest peers).

Absent authentication in the transport, however, a network attacker can still partition you even if you get node pointers from blocks. This diminishes the potential benefit.
949  Bitcoin / Development & Technical Discussion / Re: Help trying to send multisig raw transaction on: April 05, 2015, 10:20:08 AM
Public keys can be 'compressed', private keys are just private keys and can't be compressed.
Private keys have a flag to indicate if they're to be used with compression or not, as the compressed/uncompressed pubkeys are distinct; the flags are needed to make the private keys distinct too.
950  Bitcoin / Development & Technical Discussion / Re: Multisig questions on: April 05, 2015, 10:18:08 AM
1. Why the f# didn't they add the option to use also bitcoin addresses (instead of only public keys) to create multisig addresses? I am sure there must be a strong reason but I don't see it at the moment. Many users don't know their public keys immediately, and some (e.g. Circle etc.) don't know them at all.
2. When a multisig transactions has been partly signed, how can the other allowed signatories be notified? (besides emailing them).
If someone can't give you their pubkey then they almost certainly cannot sign for a multisig. You cannot just go and grab random keys from people and expect them to be able to use them in random ways!   Thats handing someone a safe and saying "what do you mean you can't open it? it's keyed with a fragment from your DNA; you've got like a trillion copies of that inside you!"; beyond the basic bit of protection from doing something boneheaded there, using hash160s there would basically double the amount of data needed in the blockchain for a multisig transaction; and would much more rapidly run into the redeemscript size limits.

For (2) thats up to the software you're using.
951  Economy / Service Discussion / Re: How to improve your Bitcoin accessibility. on: April 05, 2015, 10:13:29 AM
APIs like that can feed you completely bogus data, at their whim, like payments that never really happened, causing you to give away goods.  Even if you log the results, you can't even prove to third parties that the API lied to you.

Services like that often use third party 'dos mitigation' services that they had their SSL keys over to (and, of course, the security provided by SSL is paper thin in practice).

Like many things, these things are perfectly secure if you have nothing to lose... otherwise? not so much.

Bitcoin was design to eliminate the need for this kind of trust; too bad that so many have rusted to rebuild it in Bitcoin, rather than contributing to make the trustless infrastructure better meet people's needs.
952  Bitcoin / Development & Technical Discussion / Re: Is bitcoin-qt able to scale with large numbers of unconfirmed txIn? on: April 03, 2015, 09:57:48 PM
That's actually kind of awesome.  How do you set that kind of test up?  You feed a script of RPC commands to add tx?  
It's actually quiet easy right now.  Use the invalidateblock rpc to kill an old block. It will disconnect the blocks after it, one a time backing off the tip... and put the transactions in the mempool. (some set of the transactions will fall out because they're descended from disconnected coinbases, but most will be in there.)

Use reconsiderblock to fix your node...

This may get broken in 0.11 since Gavin has a PR to cap the mempool size during reorgs.
953  Bitcoin / Development & Technical Discussion / Re: Is bitcoin-qt able to scale with large numbers of unconfirmed txIn? on: April 03, 2015, 05:23:36 PM
I'm seeing some possibly unstable behavior when the unconfirmed tx pool gets very large.  Right now there are 4000 unconfirmed tx
Not that we're aware of, all the involved algorithms should be log() scaling. 4000 is not very large either. I've fairly recently tested with a good month's worth of blockchain in mempool at once. (Which does indeed cause some slowness, but its orders of magnitude more than you're talking about...)
954  Bitcoin / Development & Technical Discussion / Re: Interesting github forks? on: April 03, 2015, 05:18:35 PM
Something that I've wished for in Bitcoin core itself the last few days is an option to monitor the size ( in both transactions and kilobytes) of the memory pool of unconfirmed transactions.  I've been seeing it get up to 3000 or so and staying there for hours during the last few days, while some miners continue to turn in tiny 60k blocks that have a few dozen transactions at most.  
uh.

$ ~/bitcoin/src/bitcoin-cli  getmempoolinfo
{
    "size" : 320,
    "bytes" : 562732
}


or your friendly neighborhood debug console.

Since you weren't aware of the command, I'm guessing "seeing it" means bc.i-- take that with a huge heap of salt.
955  Bitcoin / Bitcoin Discussion / Re: Easy, Plug & Play Bitcoin Nodes (Bitcoin Core 0.10) on: April 02, 2015, 09:06:22 PM
RPI -- even rpi2 -- is really underpowered for supporting Bitcoin Core-- it's embarrassingly slow compared to other inexpensive ARM systems.  Just last week Gavin was arguing for unsupporting all 32-bit systems entirely; though I believe everyone else working on Bitcoin core disagrees, it's not great to be spinning up new systems which are at the very edge of whats supportable.  Not all arm cpus are equal, and you can easily have order of magnitude differences in speed with the same nominal MHz.

Many SD cards also have very low performance and write endurance. Esp with the low memory meaning the node cannot cache much, I would expect Bitcoin core will wear out the SD card somewhat quickly unless special optimizations are made to reduce the amount of write activity.

Because of the slowness of it, the vendor here ships with a "trusted" blockchain preloaded, instead of verified from the network. The result isn't easily verifiable, so your trusting that the source (or someone who has compromised their systems) isn't backdooring it in some way-- thats a risk even the developers of Bitcoin Core wouldn't ask you to take with the binaries they put out, Bitcoin core binaries get verified by a public reproducible build process.

It's great for people to run nodes; but you should run nodes in ways that don't introduce more single points of trust in the network;  adding more nodes that ultimately depend on trusting one person or another isn't much better than people just using the node that trusted party is running.
956  Bitcoin / Bitcoin Discussion / Re: DEA Agents in Silk Road Case Face Fraud Charges on: March 31, 2015, 03:13:12 PM
I think that there must be evidence that these agents planted some or all the government's evidence that was used against Ulbricht." Given that it appears that defense made that argument under seal to the judge, and the judge rejected it, I'm guessing that there was no evidence of the sort.
That sounds like a question of fact, not of law. The judge may have erred in rejecting it.

In any case, I don't disagree with you; I was just presenting an alternative view (As you can see, I've defended your position in other posts.)-- I don't think the position I outlined is likely to go anywhere.
957  Bitcoin / Bitcoin Discussion / Re: DEA Agents in Silk Road Case Face Fraud Charges on: March 31, 2015, 03:07:05 PM
Correction to my post.  It turns out that it wasn't the case that MTGox did nothing to piss off Force and Bridges; it seems MTGox earned their ire by failing to respond to a shakedown request: http://imgur.com/a/ecQ5T (ah, Magicaltux's email screenshots are inlined in the post above).

(Force asks for 250 BTC as part of a 'partnership', Magicaltux doesn't respond, he sends more emails... later the send an "I told you so" email; the same day they filed for the warrant to seize MTGox's funds)
958  Bitcoin / Bitcoin Discussion / Re: DEA Agents in Silk Road Case Face Fraud Charges on: March 31, 2015, 06:25:50 AM
Oh yeah?  Haven't you ever heard about 'fruit from the poisoned tree'?  Force4 was the lead investigator.  Every bit of evidence is derived from his original efforts.  There is no evidence which does not come from the work product of a criminal whose efforts were per se adverse to Ross' position.  

How do you like them apples Legal Beagle?
Blackbird0's position is that there were multiple investigations. It's possible (I don't know the case well enough to know) that the other investigation was separate enough that that argument doesn't hold weight. You can see my prior post for another argument that depends less on that, but at this point in time it's not entirely good what good it will do. While the argument I gave might have sewn doubt for a jury, the jury didn't hear it and unless they're able to argue that this mess is of the right shape they won't get  a chance to try that argument in a trial court.
959  Bitcoin / Bitcoin Discussion / Re: DEA Agents in Silk Road Case Face Fraud Charges on: March 31, 2015, 06:06:22 AM
I don't think the agents made up "claims" or "crimes" that Ulbricht was supposed to have committed. But rather they committed crimes themselves, by stealing some BTC. I don't think anything that they did demonstrates that Ulbricht did not do what he was convicted of doing.

They did much more than steal some bitcoins according to the indictment. The investigators, in an effort to conceal their criminality and in bad faith did systematically conceal and destroy material evidence collected during their investigation. The investigators had administrator access to the Silk Road systems which they used to rob the silk road service and then framed the original owner of their admin account for the theft (and then, with another account, offered to conduct a "hit" against that admin to extract more money from DPR) in one of many (successful) extortion attempts they carried out over months-- spanning back long before the government had any idea who DPR might be (e.g. in April 2013 they believed it was "A.A."). Their unlawful actions were not limited to SR, e.g. Force ripped off a random user of the CoinMKT exchange to the tune of a quarter million dollars where he was moonlighting (against policy and in a conflict of interest) as their compliance officer. When Force's improper use of an administrative subpoena (to attempt to unblock his rightfully suspicious-flagged account) was reported to his  superior by Venmo (a payment processor subsidiary of Paypal) he responded by attempting to seize Venmo's accounts.

Lets put aside for a moment Force and Bridge's roles as law enforcement and read their indictment as though they were just private individuals. Considering their access, strongly established involvement (e.g. the money trail connecting _them_ to SR appears to be much stronger than the money trail connecting Ross to SR), established pattern of fraudulent and vindictive activities including framing C.G. for the theft of bitcoin; they'd make a nice direction to throw doubt at the prosecutions claims and support of Ross'  "it was someone else" argument.

Consider the counterfactual with the character portrait painted in their indictment in mind: If Force and/or Bridges had had the opportunity to take over the operation of SR (from which they could rip people off on a greater scale), would they have done so? I think the picture painted by the indictment says yes. If they had and Ross pissed them off, would they have framed him? I think the indictment says yes (or even without pissing them off: They seized MTGox's US accounts immediately after successfully getting their own funds out (to the detriment of everyone now suffering from MTGox's insolvency)). I think this is a much more powerful line of argument than "maybe magicaltux did it", at least. They destroyed evidence related to their own interactions with magicaltux (and appeared to have made a successful unlawful forfeiture against MTGox as part of their criminal activities). In the story told in the indictment, these parties had the motive, the means, and opportunity that would have permitted them to frame Ross in order to conceal their own criminality (or to protect someone else who was paying them more); and the defense was apparently prohibited from presenting this in the trial.

No doubt the prosecution did their hardest to separate out  any potentially poisoned evidence, but these parties were the states only inside eyes inside silkroad. It seems unlikely to me that any of the later evidence was derived in isolation of their input, but regardless: it appears that they'd heavily spoiled the crime scene before any of the other investigators arrived.

What this actually means in terms of the actual law and procedures in the court, but I can't imagine that it would have had no effect on the jury unless they were prohibited from hearing it, nor can I really imagine them being prohibited from hearing it if it had been anything other than law enforcement agents (e.g. if it had just been other random criminals).  But they were. I can't imagine why the defense didn't delay the trial so that more of this information could be presented.

This information has certainly made a number of strange things I observed make more sense.

Edit: Ah, I see Ross' attorney has made a statement: http://freeross.org/ulbrichts-attorneys-statement-regarding-silk-road-corruption/   Seems that I called at least part of their approach, plus apparently the state used the existence of this other prosecution to suppress other evidence from being presented.  Hopefully Dratel will now move to have whatever relevant filings or orders were made regarding this unsealed, so we can get a more objective view of how much this prejudiced the case.
960  Bitcoin / Development & Technical Discussion / Re: trustless address lookup for thin-clients on: March 30, 2015, 04:17:38 PM
There is a recent study showing an attack that exploits the way bitcoin core handles addr messages and chooses peers.
That particular work is irrelevant here, Bitcoin core is intrinsically safe against the attacks this poster is describing. What SPV nodes do to different (and usually inherently less safe).
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 97 98 ... 238 »
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!