 Show Posts
|
|
Pages: « 1 2 [3] 4 5 6 »
|
https://mailman.stanford.edu/pipermail/liberationtech/2013-June/009257.htmlHi,
I'm really excited to say that Tor Browser has had some really important
changes. Mike Perry has really outdone himself - from deterministic
builds that allow us to verify that he is honest to actually having
serious usability improvements. First, thanks for the praise, Jake! But: I've been meaning to clarify this "honesty" point for a few days now, and Cooper's similar statement in another thread about security being all about trust reminded me of it. I actually disagree with the underlying assumptions of both points. I didn't spend six agonizing weeks (and counting) getting deterministic builds to work for Tor Browser to prove that I was honest or trustworthy. I did it because I don't believe that software development models based on single party trust can actually be secure against serious adversaries anymore, given the current trends in computer security and "cyberwar". For the past several years, we've been seeing a steady increase in the
weaponization, stockpiling, and the use of exploits by multiple
governments, and by multiple *areas* of multiple governments. This
includes weaponized exploits specifically designed to "bridge the air
gap", by attacking software/hardware USB stacks, disconnected Bluetooth
interfaces, disconnected Wifi interfaces, etc. Even if these exploits
themselves don't leak (ha!), the fact that they are known to exist means
that other parties can begin looking for them.In this brave new world, without the benefit of anonymity to protect oneself from such targeted attacks, I don't believe it is possible to keep a software-based GPG key secure anymore, nor do I believe it is possible to keep even an offline build machine secure from malware injection anymore, especially against the types of adversaries that Tor has to contend with. This means that software development has to evolve beyond the simple models of "Trust my gpg-signed apt archive from my trusted build machine", or even projects like Debian going to end up distributing state-sponsored malware in short order. This is where deterministic builds come in: any individual can use our anonymity network to download our source code, verify it against public signed, audited, and mirrored git repositories, and reproduce our builds exactly, without being subject to such targeted attacks. If they notice any differences, they can alert the public builders/signers, hopefully using a pseudonym or our anonymous trac account. This also will eventually allow us to create a number of auxiliary authentication mechanisms for our packages, beyond just trusting the offline build machine and the gpg key integrity. I believe it is important for Tor to set an example on this point, and I hope that the Linux distributions will follow in making deterministic packaging the norm. (Don't despair: it probably won't take 6 weeks per package. Firefox is just a bitch). Otherwise, I really don't think we'll have working computers left in 5-10 years from now :/. I hope to write a longer blog post about this topic on the Tor Blog in the next couple weeks, discussing the dangers of exploit weaponization and the threats it poses to software engineering and software distribution. I'm still mulling over the exact focus and if I should split the two ideas apart, or combine them into one post... Ideas and comments welcome!
|
|
|
|
How obvious does it need to be that someone's got a short position to cover and so is spamming off topic messages all over the forum trying to FUD the price down before that person's ability to do so is restricted?  |
|
|
|
For the last few months I've been working with keelba on a project to help jump start Bitcoin adoption and we're finalizing preparations to launch. What we are going to announce is a non-profit organization (name TBD) dedicated to organizing and promoting Bitcoin awareness and education events. We're going to target the growing number of non-IT professionals who are hearing about Bitcoin but aren't sufficiently computer and investment savvy to jump in unaided. So far we've gotten a great response from our proof of concept events and think this is the way to go to grow adoption to the next level. The way it will work is that we'll work with local Bitcoin groups in cities across the US to schedule seminar events, and we'll use combination of donations, entry fees, and vendor table charges to fund a broad spectrum marketing campaign. Our initial goal is small events which bring in 25 new Bitcoin users at a time, starting with monthly events and working up to every weekend. In about a year we'd like to grow these events to the 500-1000 person scale per weekend as the campaign progresses. At the present time we're not yet ready to start accepting donations or scheduling events, but we are looking to make contact with local Bitcoin groups who would be willing to help us identify potential venues and promote them in their area. Interested parties are invited to contact us via the PM system or in this thread. |
|
|
|
|
Bad news: My left arm is going to be out of commission for a few weeks due to a wrist sprain.
Good news: Corticosteroids and narcotic painkillers are proof that god loves us and wants us to be happy.
|
|
|
|
An electric company decides they want to use combine Bitcoin as a payment system with smart meter technology to enable real time billing. To their existing smart meter they add lightweight Bitcoin node and wallet capability. The meter does not store a full copy of the blockchain but instead relies on UBC-aware nodes to get accurate balance information. Transaction signing is handled on the meter side by a dedicated chip that refuses to sign any transaction with outputs addresses other than its own change addresses or to an address derived from the extended public key stored in a SIM-like card provided by the electric company to each subscriber. That same card also contains a 256 bit random shared secret to encrypt communications between the meter and the electric company. Both the meter and the electric company are using hierarchical deterministic wallets. The meter uses BIP32 to calculate change and deposit addresses and the electric company uses the same protocol to create a different extended public key for each customer account. Customers are reminded to add funds to their meter on a periodic basis, and the actual billing is handled on a per watt-hour basis using rapidly adjusted micropayments. Even with a very short billing interval transactions only need to hit the blockchain between once per week and once per month. The electric company likes this because they never need to deliver electricity without being assured of payment, and the customers like this because it avoids the downside traditionally associated with prepaid services - their ability to get a full refund for the unused portion of a prepayment is guaranteed by the blockchain and the Bitcoin protocol instead of the whims of the service provider. |
|
|
|
|
Big picture questions about how Bitcoin should be developed can't be productively discussed unless the participants understand each other's goals. The right direction to take depends on the desired goal, so the goal of this poll is to see what the users of this forum think the goal should be.
|
|
|
|
I ran into a couple issues while installing 0.88 on a Gentoo system and trying to figure out how best to package it, and these are some things that would make it easier: - It should be possible to specify command line parameters, especially -datadir, in an optional /etc/armory/armory.conf configuration file.
- If the blockchain files can not be found at the specified location, have a list of fallback locations to search through before giving up.
- If the node can not be contacted via localhost:8333, obtain a list of other network interfaces on the system and check those addresses before giving up and going into offline mode.
- Even better, search for a bitcoin.conf file and if it is found parse the bind=<foo> entries.
|
|
|
|
We're not quite there yet, but pretty damn close: http://bitcoinwatch.com/PetaFLOPS 967.52 Got there sooner than anyone thought: http://en.wikipedia.org/wiki/Exascale_computingExascale computing refers to computing systems capable of at least one exaFLOPS. Such capacity represents a thousandfold increase over the first petascale computer that came into operation in 2008.[1] (One exaflop is a thousand petaflops or a quintillion, 1018, floating point operations per second.) At a supercomputing conference in 2009, Computerworld projected exascale implementation by 2018.[2] |
|
|
|
|
I'm putting forward this scenerio because even though I though I understood what was going on with Ripple transactions, I found myself not being entirely certain about the mechanics:
Alice, Bob, and Carol are all friends. Alice and Bob both live in New York and Carol lives in Los Angeles.
Bob borrows $100 from Alice. At some point after he's ready to repay her, but before having done so, he takes a business trip to LA. While he's there Alice remembers that it's Carol's birthday and tells Bob giving the $100 bill to Carol. Now everyone has been paid in full.
Suppose they decide to use Ripple to track the movements of this $100 bill. They all start with fresh wallets containing nothing except enough XRP to be able to conduct transaction. Who extends trust to whom and at what point, what transactions happen in the Ripple network, and what is the state of everyone's wallets and trust relationships at the end of this scenario?
|
|
|
|
Stefan Molynuex announced today that he's been diagnosed with lymphoma. Apparently the prognosis is good (as far as those things go) but he was unable to obtain an accurate and timely diagnosis within the Canadian medical system and had to travel internationally in order to purchase effective care. http://www.youtube.com/watch?v=Iwmr1elnxjg |
|
|
|
|
"When I say I hate CVS with a passion, I have to also say that if there any SVN users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started, because the whole slogan for the Subversion for a while was “CVS done right” or something like that. And if you start with that kind of slogan, there is nowhere you can go. It’s like, there is no way to do CVS right."
--Linus Torvalds
Ripple and Bitcoin both attempt to solve the problem of digital currency but approach it from opposite ideological perspectives. Ripple recognizes that the existing financial system works as a series of IOUs and attempts to improve the manner in which they are transacted. Bitcoin attempts to make IOUs unnecessary by making the transfer of actual currency as easy as the transfer of IOUs. In the same way, Subversion attempts to make centralized version control better while Git proposed that centralized version control is broken by definition and instead implemented decentralized version control. I propose that Ripple can be at best the implementation of a broken paradigm that sucks less than everything else.
The central question is, "Under what circumstances, if any, should we trust a third party to hold on to our money for us?" If you assume that allowing third parties (gateways in the Ripple system, banks in the legacy financial sector) to hold money for users is a good idea then Ripple looks pretty good in terms of usability. Just because the legacy financial system works this way, however, does not mean it's true.
The benefits of entrusting the storage of money to third parties are dubious even under the best of circumstances. Even before modern times when money was held as gold or paper notes, storing money in a bank was a tradeoff between different risks of theft. On the one hand the bank has a stronger safe and so could resist physical theft better than most individuals, but on the other hand any thief with sufficient resources to overcome the bank's defenses could get away with a lot of money. Oh, and there's also the small matter that if everybody gives their money to the bank it's really easy for the bank to steal it.
In the modern era both of these risks are amplified. Financial institutions have a terrible track record when it comes to not losing or stealing their clients' money. This is even more true when it comes to companies who operate in the Bitcoin economy using business models based on legacy financial principles. The reason we need trustless financial systems is because trust just doesn't work. As companies which store client funds are more successful, they gain more trust. As they gain more trust people give them more money to store. As the amount of money they store increases, so does the bullseye painted on them.
Larger piles of money are more attractive to thieves. Even if we assume the operators of theses services have the best of intentions and perfect integrity that's not enough to say it's a good idea to trust them to store money. At some point these operators will need to hire employees. That creates the risk of an inside job that only grows as the company becomes more successful. At the same time, thieves who don't want to go to the trouble of getting a job there will attempt remote attacks. This is a huge problem because fundamentally we're losing the battle when it comes to computer security. The capabilities of the attackers scales exponentially while the abilities of defenders to resist attack is scaling linearly. The same feedback loop that causes the most trustworthy companies to attract the most customer money means the most trustworthy companies will be the most attractive to attack.
The only viable way to defend against decentralized attackers is decentralized defense. Everybody hold on to their own money instead of aggregating it at centralized points of attack. This reduces the cost/benefit ratio for attackers, thus making theft less profitable. This seriously undermines the utility of any system which relies on trusted entities to hold client funds, and makes the use case for Ripple as it currently is presented highly questionable.
This doesn't mean that I am entirely opposed to it, however. Even though trustless systems are the future we're going to be stuck with the legacy financial for a while, and the existing methods for transferring value in that system suck so badly that Ripple is a huge improvement. In that way it makes a great transitional technology.
In summary: use Ripple as a way to make the times that you're forced to handle legacy currencies far more enjoyable. Don't accept a Bitcoin IOU in lieu of the real thing though. There's no need for it and sooner or later pretending that IOUs are just as good as actually having BTC will always end in tears.
|
|
|
|
|
I made a BoA deposit at approximately 2200 UTC, and still haven't seen it credited to my Bitfloor account. According to emails received from both LocalTill and Bitfloor there is some kind of technical difficulties that are affecting all cash deposits.
Has anyone else had this problem, or can anyone say when they most recently made a successful deposit to Bitfloor via LocalTill?
|
|
|
|
|
Does anyone know of an Android app for YouTube that is reliable enough to watch an entire video without crashing, and that allows one to skip to a timestamp and actually expect to have the video start playing from that point?
The one from Google does none of those things for me. Videos usually start playing reliably, but long ones won't go all the way through before a data transfer problem hangs the stream. If I pause a video and later try to resume playback I've found this only works about 10% of the time. If I try to load the video again and skip forward to where I left off this basically never works.
Even over wifi, watching a YouTube video on my phone feels like it's 1993 again and I'm trying and failing to download a 1 MB file from a BBS.
|
|
|
|
|
$0.10 2010-10-13
$0.13 2010-10-25
$0.16 2010-10-26
$0.20 2010-12-11
$0.25 2010-12-20
$0.32 2011-01-20
$0.40 2011-01-21
$0.50 2011-01-31
$0.63 2011-02-01
$0.79 2011-04-12
$1.00 2011-04-16
$1.26 2011-04-22
$1.58 2011-04-26
$2.00 2011-04-28
$2.51 2011-11-29
$3.16 2011-12-15
$3.98 2011-12-25
$5.01 2012-05-16
$6.31 2012-06-19
$7.94 2012-07-16
$10.00 2012-09-02
$12.59 2012-12-04
$15.85 2013-01-21
$19.95 2013-02-03
$25.12 2013-02-13
$31.62 2013-02-28
$39.81 2013-03-06
$50.12 2013-03-19
$63.10 2013-03-24
$79.43 2013-07-10
$100.00 2013-07-29
$125.89 2013-10-03
$158.49 2013-10-18
$199.53 2013-10-27
$251.19 2013-11-06
$316.23 2013-11-08
$398.11 2013-11-13
$501.19 2013-11-18
$630.96 2013-12-19
$794.33 2013-12-30
$1,000.00
$1,258.93
$1,584.89
$1,995.26
$2,511.89
$3,162.28
$3,981.07
$5,011.87
$6,309.57
$7,943.28
$10,000.00
$12,589.25
$15,848.93
$19,952.62
$25,118.86
$31,622.78
$39,810.72
$50,118.72
$63,095.73
$79,432.82
$100,000.00
$125,892.54
$158,489.32
$199,526.23
$251,188.64
$316,227.77
$398,107.17
$501,187.23
$630,957.34
$794,328.23
$1,000,000.00
|
|
|
|
I think the wiki article for Scalability is not ambitious enough; Bitcoin should be capable of processing 1 million transactions per second by 2030. This allows a population of 10 billion to each initiate 100 transactions per day. Can it be done on hardware expected to be available to average users in 2030? What changes would need to be implemented to allow Bitcoin to scale to this level? Using the ratio from the Bitcoin wiki, 1 million transactions per second requires about 4 gigabits per second. If Nielsen's Law of Internet Bandwidth holds until 2030 this amount of bandwidth will be start to become available to home users by 2022, and should be a small fraction of the average 2030 user's connection. Broadcasting 1 million tps through the network would not appear to be a problem by 2030. Transmitting blocks as they are currently constructed would be a problem, because right now they include a complete copy of every transaction so require a burst bandwidth much higher than the average in order to distribute blocks in a timely fashion. There's no reason this must remain the case, however. Assuming that all nodes have a method of retrieving transactions which are not in the memory pool, the block could consist of a header and a list of hashes. This reduces the size of a block by a factor of 16 (512 byte transaction / 256 bit hash). A miner could reduce the requirement for burst bandwidth further by pre-announcing the transactions which will occur in their block so that only the nonce and final hash would need to be broadcast when they solve a block. CPU: If a common 2012 CPU can process 4000 tps, then a 2030 CPU should be able to process over 100 million tps by Moore's Law. Storage: Requiring each node to store a complete copy of the entire blockchain back to the genesis block is excessive. A distributed, redundant, content-addressable data store could serve the function of storing history and broadcasting transactions. We already have an example of such a datastore in Freenet. Freenet's datastore is useful for this application because nodes automatically specialize without any explicit configuration, and the inter node routing adjusts to demand in real time in order to converge on an optimal configuration. Commonly-requested data is intelligently cached and the store has a provision for pruning unneeded keys when a node runs out of storage space. The P2P aspect of Freenet is slow due to it being optimized for privacy, but without that requirement other performance enhancements are possible. |
|
|
|
|
Anyone who has been watching Bitcoinity during this morning has witnessed a great example of how to handle communications during an upgrade.
The way they have kept users of the site informed of the pending changes before, during, and after the attempted upgrade stands out in a positive way as compared to some other services.
|
|
|
|
|
