No, I think they have too much of a strangle hold on this particular market, and I believe the cost of providing electronic transactions should be decreasing.
I have no problem with the government replacing the bank credit card system. That is, if they can reduce or eliminate the 2%(ish) merchant fee that everyone must currently pay to the bank cartels to use it.
This is exactly what is happening in South Africa right now. Though the government didn't start the project, they have started printing open text books for all students.
True, but since the order of the chapters is an important feature of how the work is used, this is mainly a reverse engineering effort for the purpose of interoperability. "For homework read chapters 4-6" would be an impossible instruction to follow if you didn't have a text laid out in the same order.
If you're talking about Open ID, then you aren't actually providing your facebook username and password. You're just linking these things you do on other sites to your facebook identity.
The only reason ISP's wont offer more than 100Mbps, is because they will have to fork over $4,000 per month, per peering point just to supply enough peak bandwidth for one customer to get 100Mbps while other people are also using their connections. To provide just 1Gbps at one peering point, will cost an ISP $40,000 per month. Even if you only have one customer who barely uses their connection.
That's certainly possible. I was playing around writing a tool that could do that kind of thing maybe 8 years ago, but it was never stable enough to release.
That's just the description of the camera they built. Now someone is publishing about something else they can do with it. If you spend all that time building a cool piece of equipment, you're going to have a small team of students writing as many related papers as possible. Not really surprised.
But then every time we hit these limits we tend to double the bit count which pushes out these limits *much* further. 2^128 ought to be enough for anybody, but once we go to 2^256 we'll never hit it.
You buy a chunk of a company, the company gets the cash from the sale to invest, the company profit's from their investment, you are paid your share of the profits. And if you later wish to sell your piece of the company, it should be valued based on the income stream it generates.
But it seems the market is only really interested in asset speculation. And since you can borrow money against shares, taking out a loan and paying interest on that loan is cheaper from a tax liability point of view. Which is really fucked up.
Yeah I overheard a similar conversation at linux conf au in January. No idea who the guy was, or who he worked for, but Jacob Appelbaum seemed fairly interested for some reason...
In a nut shell, TCP was designed to share a limited network pipe by slowing down the transmission rate of any user when packets are unable to be delivered, assuming that each router would drop packets when they ran out of memory and/or available bandwidth. This way people who need a fast response from a remote server aren't slowed down by somebody else's file transfer. Another design idea in TCP allows for a number of packets to be in flight over very long network paths. If you only allowed for one packet at a time file transfers would be very slow.
So if a network router just queue's all packets indefinitely and never drops them, no application using the network can tell the difference between a full network queue, or a link that is longer or just using slower technology. Of course these days memory is cheap, and manufacturers allocate too much memory to network queue's. Heck even the linux kernel (I believe) defaults to a packet queue length of 1,000.
For a linux router, the best thing to do is throttle your upstream connection so it is slightly slower than the smallest bottleneck between you and the internet (eg your modem). That way the modem's buffer can't fill up at all. And then make sure your transmit queue is tiny, dropping any packets that don't fit. And then of course you can apply QoS rules to make sure packets that need an immediate response are sent first.
I didn't say I had a solution for the initial handshake. But once you know the PK for "Bank of America" you know with every connection to them that it is still "Bank of America". If you publish your PK with a cert from Verisign, well maybe I'll trust it a little more.
I've floated an idea like this before; Use something like a Distributed Hash Table, publish a signed record with the current location of your name server, using your public key as the DHT key. Then when people connect to services on your hosts, use the same key to encrypt communications. Once people know your key they can always securely connect to you. Search engines could then harvest the keys in the DHT to discover new hosts to index. Though the initial process for key discovery might still be susceptible to MITM attacks.
Not all numbers can be accurately converted to the form; +/- (1 [+ 1/2] [+ 1/4] [+ 1/8].... ) * 2^n. Basically floating point can't accurately represent any rational number that has a prime factor other than 2. Of course 4 is a number that *can* be accurately described.
Siyavule in South Africa are starting something exactly like that. Open source texts, not just so that they are free, but with the goal of being much better than the existing texts.
Only some machines need to keep the entire log as it is only interesting if you need to rebuild the list of active tokens. Even mining machines don't need it to generate new valid log segments. A bitcoin transaction has this kind of structure; [[list [consumed tokens]], [list [new token owner and $]] [signature of old owner]. The list of consumed tokens is just a list of hashes. If you want to verify that this new transaction is valid, you only need to confirm that these consumed tokens are still in the list of active tokens. You don't need every node in the network to traverse the entire history of these tokens as multiple other nodes have already done so and can independently agree on the contents of the set of active tokens. You don't need a new token to be issued to reduce the volume of data that must be examined. In a logical sense the entire history of the transaction chain of a token will get longer, but you don't need every node to store it forever. Sure the amount of space you need to maintain the set of active tokens is still going to grow, but not as fast as the log.
The total log size grows, but the individual tokens shouldn't change in size. Is every client storing the entire transaction chain for all the coins you own? That's silly. This is why a transaction refers to the previous transactions it is consuming by the hash of the transactions, you can verify a signature without traversing the entire history. Sure a number of clients in the network will need to store the entire log file so new clients can re-validate it. But once everyone agrees that a token has been consumed you don't actually need to store it any more. A non-mining client that is tracking the global log only needs to keep transaction information for the current owner of each unspent token.
Sure Bitcoin is deflationary, but the total stock of coins is irrelevant for measuring your ability to pay off a debt. The only thing that matters is your income flow. Provided the bitcoins you are using to pay your debt continue to circulate, you could keep receiving the same coins as income. It is absolutely possible to pay off large debts using a currency with a limited stock of tokens.
Slashdot Mirror
I found this thread, but I don't know anything about its quality.
No, I think they have too much of a strangle hold on this particular market, and I believe the cost of providing electronic transactions should be decreasing.
I have no problem with the government replacing the bank credit card system. That is, if they can reduce or eliminate the 2%(ish) merchant fee that everyone must currently pay to the bank cartels to use it.
This is exactly what is happening in South Africa right now. Though the government didn't start the project, they have started printing open text books for all students.
True, but since the order of the chapters is an important feature of how the work is used, this is mainly a reverse engineering effort for the purpose of interoperability. "For homework read chapters 4-6" would be an impossible instruction to follow if you didn't have a text laid out in the same order.
Like some kind of reverse Lytro?
If you're talking about Open ID, then you aren't actually providing your facebook username and password. You're just linking these things you do on other sites to your facebook identity.
The only reason ISP's wont offer more than 100Mbps, is because they will have to fork over $4,000 per month, per peering point just to supply enough peak bandwidth for one customer to get 100Mbps while other people are also using their connections. To provide just 1Gbps at one peering point, will cost an ISP $40,000 per month. Even if you only have one customer who barely uses their connection.
... and have all usage billed to my account.
I believe that the 802.11ai working group is working towards that goal.
If the virtual desktop is based on the built in support for multiple desktops, then no.
That's certainly possible. I was playing around writing a tool that could do that kind of thing maybe 8 years ago, but it was never stable enough to release.
That's just the description of the camera they built. Now someone is publishing about something else they can do with it. If you spend all that time building a cool piece of equipment, you're going to have a small team of students writing as many related papers as possible. Not really surprised.
But then every time we hit these limits we tend to double the bit count which pushes out these limits *much* further. 2^128 ought to be enough for anybody, but once we go to 2^256 we'll never hit it.
IMHO that's how things should be.
You buy a chunk of a company, the company gets the cash from the sale to invest, the company profit's from their investment, you are paid your share of the profits. And if you later wish to sell your piece of the company, it should be valued based on the income stream it generates.
But it seems the market is only really interested in asset speculation. And since you can borrow money against shares, taking out a loan and paying interest on that loan is cheaper from a tax liability point of view. Which is really fucked up.
Yeah I overheard a similar conversation at linux conf au in January. No idea who the guy was, or who he worked for, but Jacob Appelbaum seemed fairly interested for some reason...
In a nut shell, TCP was designed to share a limited network pipe by slowing down the transmission rate of any user when packets are unable to be delivered, assuming that each router would drop packets when they ran out of memory and/or available bandwidth. This way people who need a fast response from a remote server aren't slowed down by somebody else's file transfer. Another design idea in TCP allows for a number of packets to be in flight over very long network paths. If you only allowed for one packet at a time file transfers would be very slow.
So if a network router just queue's all packets indefinitely and never drops them, no application using the network can tell the difference between a full network queue, or a link that is longer or just using slower technology. Of course these days memory is cheap, and manufacturers allocate too much memory to network queue's. Heck even the linux kernel (I believe) defaults to a packet queue length of 1,000.
For a linux router, the best thing to do is throttle your upstream connection so it is slightly slower than the smallest bottleneck between you and the internet (eg your modem). That way the modem's buffer can't fill up at all. And then make sure your transmit queue is tiny, dropping any packets that don't fit. And then of course you can apply QoS rules to make sure packets that need an immediate response are sent first.
I didn't say I had a solution for the initial handshake. But once you know the PK for "Bank of America" you know with every connection to them that it is still "Bank of America". If you publish your PK with a cert from Verisign, well maybe I'll trust it a little more.
I've floated an idea like this before; Use something like a Distributed Hash Table, publish a signed record with the current location of your name server, using your public key as the DHT key. Then when people connect to services on your hosts, use the same key to encrypt communications. Once people know your key they can always securely connect to you. Search engines could then harvest the keys in the DHT to discover new hosts to index. Though the initial process for key discovery might still be susceptible to MITM attacks.
Not all numbers can be accurately converted to the form; +/- (1 [+ 1/2] [+ 1/4] [+ 1/8] .... ) * 2^n. Basically floating point can't accurately represent any rational number that has a prime factor other than 2. Of course 4 is a number that *can* be accurately described.
And if the gun manufacturer was taped giving advice on how to use the gun to rob a bank, knowing that the customer was going to follow their advice?
Siyavule in South Africa are starting something exactly like that. Open source texts, not just so that they are free, but with the goal of being much better than the existing texts.
Or this one?
Only some machines need to keep the entire log as it is only interesting if you need to rebuild the list of active tokens. Even mining machines don't need it to generate new valid log segments. A bitcoin transaction has this kind of structure; [[list [consumed tokens]], [list [new token owner and $]] [signature of old owner]. The list of consumed tokens is just a list of hashes. If you want to verify that this new transaction is valid, you only need to confirm that these consumed tokens are still in the list of active tokens. You don't need every node in the network to traverse the entire history of these tokens as multiple other nodes have already done so and can independently agree on the contents of the set of active tokens. You don't need a new token to be issued to reduce the volume of data that must be examined. In a logical sense the entire history of the transaction chain of a token will get longer, but you don't need every node to store it forever. Sure the amount of space you need to maintain the set of active tokens is still going to grow, but not as fast as the log.
The total log size grows, but the individual tokens shouldn't change in size. Is every client storing the entire transaction chain for all the coins you own? That's silly. This is why a transaction refers to the previous transactions it is consuming by the hash of the transactions, you can verify a signature without traversing the entire history. Sure a number of clients in the network will need to store the entire log file so new clients can re-validate it. But once everyone agrees that a token has been consumed you don't actually need to store it any more. A non-mining client that is tracking the global log only needs to keep transaction information for the current owner of each unspent token.
Sure Bitcoin is deflationary, but the total stock of coins is irrelevant for measuring your ability to pay off a debt. The only thing that matters is your income flow. Provided the bitcoins you are using to pay your debt continue to circulate, you could keep receiving the same coins as income. It is absolutely possible to pay off large debts using a currency with a limited stock of tokens.