|
21
|
Bitcoin / Development & Technical Discussion / Re: Is the security of the trusted root cert the weak link in BIP-70?
|
on: January 16, 2015, 03:42:42 PM
|
True, in that case root certificates aren't the weak link, but I can think of situations where it would be. Trusting a root certificate implies trusting a centralized certifying authority. The authority can be compromised to issue and sign fake certificates to facilitate MITM attacks. Governments have already coerced a few CAs into facilitating MITM attacks on SSL/TLS in the past.
Even in that case, the certificate is " a" weak link, not " the" weak link. Think through what would have to fail to pull off a steal-bitcoins attack in the multisig-wallet case: 1) User has to be directed to an attacker-controlled payment website. That means either DNS lookup is compromised or the user's connection to the Internet is compromised (weak link number 1). 2) Attacker serves up a signed PaymentRequest with a valid certificate signed by a compromised root certificate authority (weak link number 2). If the attacker can accomplish (1), it is likely they would just serve up unsigned payment requests from a non-secure website and bet that the user doesn't notice the lack of a padlock in the web browser UI and agrees to pay to an unauthenticated bitcoin address. (1) is mitigated if the payment website uses HSTS headers so any repeat visitors get a HTTPS connection-- that pushes the attack to "must compromise both the connection and be able to spoof the web server certificate". Strike that, if their computer is compromised HSTS headers won't help. In any case, I wouldn't say the root certificates are a single point of failure. |
|
|
|
|
24
|
Bitcoin / Bitcoin Discussion / Re: Gavin Andresen on the front page of the FT
|
on: January 14, 2015, 05:37:01 PM
|
I applaud him for his intentions and honesty but I would suggest this is going too far as I would be comfortable recommending my luddite mother invest a couple thousand on the side and store it in the insured multisig vault with coinbase. People should diversify their investments and that includes partially investing into Bitcoin.
Really? If your luddite parents' computer might already be compromised, they cannot securely connect to coinbase (or circle or any other easy-enough-for-a-luddite-to-use service) to set up an account. The might THINK they're connecting to coinbase/circle/whoever, but malware could be man-in-the-middle attacking the website they're looking at. They think they're opening an account at coinbase/circle/whatever... but they're just giving the attacker all their bank account information, getting bitcoin 'deposit' addresses from the attacker, etc. Your parents will have no clue until their bank tells them about odd wire transfers or they try to send bitcoin somewhere, it fails, and coinbase customer support tells them "Sorry, can't help you, you don't have an account with us." I would say the same about traditional online banking, except your luddite parents almost certainly already have a relationship with their bank, and the bank already knows their name and how to contact them. And it is harder for an attacker to man-in-the-middle the fiat banking system and get away with it, since identities are tied to bank accounts, wire transfers, etc. I don't know how the "Bitcoin for Luddites" problem will be solved. Maybe hardware wallets, maybe hardware authentication tokens, maybe Apple or Google will get iPhone or Android security tight enough to trust, maybe it will take "come to our branch to set up an account" to get good-enough security and usability. |
|
|
|
|
26
|
Bitcoin / Development & Technical Discussion / Re: What is latest good practice to store data in a transaction
|
on: January 07, 2015, 02:54:43 PM
|
Three important points to consider about OP_RETURN:
1) A transaction can only have one OP_RETURN output. Two or more is simply invalid (not non-standard but invalid) and will be rejected by all nodes.
2) The "payload" of the OP RETURN output is limited to 40 bytes. More than 40 bytes is invalid as well.
4) The OP_RETURN output is unspendable and thus normally should have a value of 0 BTC however be aware you can set it to any valid value and if you do so accidentally then the coins are effectively destroyed.
"Three sir!" Actually, 1 and 2 aren't correct: the one-output and only-40-bytes checks are "what is a standard transaction" policy rules. If you can get a miner to include it in a block, a transaction with 11 100-byte OP_RETURN outputs is valid. |
|
|
|
|
27
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin Foundation Election
|
on: December 29, 2014, 09:38:52 PM
|
RE: can't wrap your head around what the Bitcoin Foundation does: It is in big letters at the new https://bitcoinfoundation.org/ home page: WHAT WE DO:
Fund development for Bitcoin
Core and common-good
bitcoin infrastructure See the blog post from last month on the Foundation's "pivot" to focus on development and infrastructure: https://blog.bitcoinfoundation.org/everybody-pivots/RE: "The Board appears to have not settled on an exact date": Settled 11 days ago; see https://blog.bitcoinfoundation.org/elections-update/ for the exact dates for the two individual seats. The election dates for the 'affiliate member seat' isn't yet set, the process for affiliate organizations to nominate and then cast their votes is still being worked out (and you don't need to care, unless you are part of the leadership of one of the Foundation's affiliate organizations and need to figure out how you and your members will come to consensus on how to vote). |
|
|
|
|
28
|
Bitcoin / Bitcoin Discussion / Re: Gavin will visit the Council on Foreign Relations
|
on: December 12, 2014, 08:41:39 PM
|
You're right. That was Gavin-bait. Well David Rabahy it's been six months and still no field report. Maybe next year. lol
Huh what? Field report from my talk at the CFR? I barely remember it, there were probably 50 people in suits in the audience, nobody I recognized. The whole thing is on video, there were no secret meetings, I got there 10 minutes before my talk and left 10 minutes after (I had a bunch of interviews with DC-based journalists scheduled... and I think that was the trip I had lunch with Jim Harper and got a tour of Cato, although I might be mis-remembering). |
|
|
|
|
29
|
Bitcoin / Bitcoin Discussion / Re: man sentenced to 4 years for illegal bitcoin operation
|
on: December 10, 2014, 08:03:02 PM
|
why is that illegal to run bitcoin exchange? its not real money
It's being exchanged for real money. Therefore, according to the law in Illinois, you have to have a Money Service Business license or face felony charges. I am not a lawyer, but... ... the money transmission laws and regulations are written very broadly. They almost certainly apply even if you are exchanging one crypto-currency for another, and no "real money" is involved. The only saving grace is that the laws only apply if you are operating "a business" -- so occasional lowish-value person-to-person exchanges done as a favor to friends at no markup from the current exchange rate is probably perfectly legal. |
|
|
|
|
30
|
Bitcoin / Development & Technical Discussion / Re: crypto software - writing the grotty bits.
|
on: December 03, 2014, 01:45:50 PM
|
|
Excellent advice.
I'd add: you never have infinite time, so you will have to prioritize.
Cryddit's original post talks a fair bit about preventing data leakage in side-channel attacks; I'll just say that if you only have time to either get 100% code path unit test coverage or hand-code some assembly to workaround your compiler leaving a private key in memory instead of a register... I'd work on the test coverage.
And if the choice is between 100% test coverage versus 91% with support for threshold signatures on multiple devices-- I'd choose threshold signatures.
And, of course, the highest priority is creating a product or service that is both trustworthy and that people want to use.
|
|
|
|
|
31
|
Bitcoin / Development & Technical Discussion / Re: O(1) block propagation
|
on: November 20, 2014, 08:45:23 PM
|
If you want to work on IBLT stuff... ... start with Matt's fast-relay code: https://github.com/TheBlueMatt/RelayNodeThat is an "I know what I've already told my peers, so I won't tell them again" optimization for transaction data. I haven't tried to figure out how far that already-written-and-running code lets us scale, but I think that would be the first step. Once you understand what Matt is doing, then figure out how an IBLT can further optimize to eliminate sending even lists of transaction IDs. The first step there is to figure out what software miners are using to build their blocks, and figuring out how hard it would be to get that software to do the IBLT thing (have similar policies for selecting transactions, and identical policies for ordering transactions inside the block). |
|
|
|
|
32
|
Bitcoin / Bitcoin Discussion / Re: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability
|
on: November 17, 2014, 06:09:44 PM
|
As best I can tell there is no ability or desire to include this level of rigor in the development of Bitcoin. As a holder I must factor this into the confidence I have in the solution.
You don't seem to have the "jump in and help" mentality needed to participate in a radically open project like Bitcoin. As I have said repeatedly in the past: you don't have to ask anybody for permission or advice. You are part of the process-- make it happen. Personally, I don't know nuthin about "opfor teams" ... (but am the creator of the Bitcoin testnet, so am offended by you saying there is no ability or desire to bring more testing rigor to Bitcoin). |
|
|
|
|
33
|
Bitcoin / Bitcoin Discussion / Re: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability
|
on: November 17, 2014, 04:59:28 PM
|
It seems Bitcoin community can't reach consensus on this issue, a lot of people against the proposal.
There seem to be a few people who want some OTHER algorithm for increasing the block size, but I'm hearing very broad consensus that we do need a hard fork to increase the size. That is progress. I'll be running some experiments using actual blockchain data to see where the current code breaks; if it can already handle 20MB blocks then I'll work through the details to propose a hard fork (write BIPs, write code, write tests, ...). |
|
|
|
|
34
|
Economy / Economics / Re: Economics of the blocksize limit
|
on: November 16, 2014, 07:41:37 PM
|
If the block size is increased such that there is enough room for all transactions....
Please be more precise. Nobody "increases the block size" -- miners choose to create larger or smaller blocks, up to the maximum block size limit. And quoting myself: (from my recent blog post): The argument is that keeping one-megabyte blocks will push up transaction fees, so as the block subsidy falls smaller blocks will make it more likely that fees will make up the difference and keep the network secure.
The counter-argument is that bigger blocks allow more transactions, so even if each transaction pays a smaller fee, the total will be greater.
I think that both of those arguments are wrong, because they are equating apples and oranges. The supply being rationed by a maximum block size is some number of bytes, which translates into a certain number of transactions. But the demand for blockchain security depends on the value and nature of the transaction; very large value transactions are typically secured by real-world contracts, long-established trust relationships, lawyers, and court systems.
So there is no guarantee that future one-megabyte blocks will be full of high-fee million-dollar transactions; it is possible we would see blocks full of tiny-fee million dollar transactions, because Gringotts Bank will take the Bank of Elbonia to court if they double-spend some large value inter-bank-settlement transaction.
There is no guarantee that future one-gigabyte blocks full of smaller transactions will generate enough fees to secure the blockchain, either. Transaction confirmation speed is important for most small-value transactions, so it is likely they will be secured using semi-trusted third parties who co-sign transactions and guarantee to never allow double-spending. And if they are secured against double-spending that way, there is little incentive for either the sender or recipient to include a transaction fee |
|
|
|
|
36
|
Bitcoin / Development & Technical Discussion / Re: Funding network security in the future
|
on: November 13, 2014, 12:23:02 AM
|
You are wrong.
Example that should make it clear....
Wait... no... that example is only valid for the "attacker takes over existing mining pools" case, where formerly honest miners are co-opted to be evil (or gang up in a cartel to be evil). If somebody collects as much hashing power as the rest of the network combined and then suddenly attacks, then yes, indeed, difficulty stays the same, the attacker gets all the mining rewards, and there are twice as many stale blocks as before. Attacker gets 6 block rewards per hour. If they were to mine honestly, blocks would be created twice as fast until difficulty adjusted, so they'd get 6 block rewards per hour for a week (same as if they decide to attack). Then difficulty would double, and they'd get only 3 per hour. |
|
|
|
|
37
|
Bitcoin / Development & Technical Discussion / Re: Funding network security in the future
|
on: November 12, 2014, 06:34:36 PM
|
Please correct me if I'm wrong, but isn't this an issue right now? Assuming that mining is profitable (i.e. mining revenue is greater than cost), a 51% attack would essentially cost nothing because the attacker would receive all the mining revenue (which exceeds his cost because we assume that mining is profitable). This is independent of subsidy in relation to transaction fees.
You are wrong. Example that should make it clear: Honest miner with 50% hash power: will mine 6 blocks every two hours (on average). Rest of the network will mine the other 6 blocks. Attacking miner with 50% hash power: will mine 6 blocks every four hours (on average), because they refuse to build on anybody else's blocks. Result: if the attacker is the longest chain, they'll get half as many BTC as honest mining (if they are unlucky and are not the longest chain, they'll get zero). If they could keep up the attack for a full month until difficulty adjusts then they'll start making what they would have been making if they were honest. |
|
|
|
|
38
|
Bitcoin / Bitcoin Discussion / Re: DO NOT GIVE THE GOVERNMENT ANY INFORMATION ABOUT BITCOIN
|
on: November 10, 2014, 06:26:48 PM
|
OP does have a point, Satoshi did walk away the moment Gavin accepted the invitation to speak with the CIA. Coincidence?
YES THAT WAS TOTALLY AND COMPLEETLY A COINCEDENCE!!!! HE WUZ PLANNING ON LEAVING WAY BEFORE THAT! I THINK THE OP IS RIGHT, SO I'M GONNA MOVE THE SOURCE CODE TO SUMPLACE MORE SECURE WHERE THE GOVERNMENT CAN'T SEE IT ANYMORE. AND I WENT AND GOT ME A GOOD HAT TO WEAR WHEN I WRITE CODE SO THEIR SATELITES CANT HEAR ME EITHER. FOR THE CHILDREN! Is this the real Gavin? Maybe someone hacked his account. I didn't expect that he had a sense of humor. Too much stress to still be funny. can anyone confirm? He is being sarcastic. He is trying to get across a point that having bitcoin be open source is much better then it be closed source and the government not have access to information about bitcoin Or maybe I just ate too much peyote one night (and, happily, decided to read bitcointalk instead of write some code). (and for the humor-impaired: NO, NOT SERIOUS. Everybody knows I don't eat peyote, I spend my money on hookers and blow.) |
|
|
|
|
40
|
Bitcoin / Bitcoin Discussion / Re: DO NOT GIVE THE GOVERNMENT ANY INFORMATION ABOUT BITCOIN
|
on: November 04, 2014, 02:45:50 PM
|
OP does have a point, Satoshi did walk away the moment Gavin accepted the invitation to speak with the CIA. Coincidence?
YES THAT WAS TOTALLY AND COMPLEETLY A COINCEDENCE!!!! HE WUZ PLANNING ON LEAVING WAY BEFORE THAT! I THINK THE OP IS RIGHT, SO I'M GONNA MOVE THE SOURCE CODE TO SUMPLACE MORE SECURE WHERE THE GOVERNMENT CAN'T SEE IT ANYMORE. AND I WENT AND GOT ME A GOOD HAT TO WEAR WHEN I WRITE CODE SO THEIR SATELITES CANT HEAR ME EITHER. FOR THE CHILDREN! |
|
|
|
|
Show Posts
