 Show Posts
|
|
Pages: « 1 2 [3]
|
I suggest the book that started the modern Austrian school: Human Action by Ludwig von Mises. It's available for free (legally) on the Internet in several formats (including PDF, ePub, and MP3) and can be purchased in paperback for about $10 USD. There's also a recent study guide written by Robert Murphy which is also freely available. Links to Human Action: Study Guide links: -Dave P.S. There are four editions of Human Action. The first edition is in the public domain and is also called the "scholars edition." Although later editions would usually be preferred, I've read that the first edition is the best and, since it is freely available, I suggest we use that one. All the links above point the first edition/scholars edition. |
|
|
|
|
I would buy $10,000 of bitcoins a day for 1,000 days. This will probably cause bitcoins to increase in value relative to the US dollar, which will encourage people to own more bitcoins and fewer dollars. The more value tied up in bitcoins, the more incentive for businesses to cater to bitcoin owners.
At the end of 1,000 days (roughly 3 years), hopefully the bitcoin economy would've grown more than $10,000,000 and I could sell 1/10% of my bitcoins a day for 1,000 days and pay my investors back a profit.
-Dave
|
|
|
|
Upon reconsideration, I think there is a way that is simpler, less specific, and much more useful. It would support paying for downloads not just on BitTorrent but any protocol--HTTP, FTP, Gnutella, and others. How it works: The uploader uses traffic shaping to assign downloaders' IP addresses into several pools. Each of these pools is allocated a maximum amount of bandwidth they may use. For example: - Abby sets pool 0 to include all downloaders who haven't paid yet. She gives them up to 25Kbs.
- She sets pool 1 to include downloaders who paid 0.01 to 0.04 BTC. She gives them up to 50Kbs.
- She sets pool 2 to include downloaders who paid 0.05 BTC or more. She gives them unlimited bandwidth. (Unlimited by Abby; her link speed or her ISP limit the connection, of course.)
It doesn't matter to Abby whether her downloaders are downloading from her BitTorrent client, her Web server, her FTP server, or any other service she provides. She also doesn't have to count bytes sent; all she needs to do is keep a simple mapping of IP addresses to payments received. Even better, Abby can join together with Ben. They both agree to use the same IP address pools with the same bandwidth limits and to split the incoming payments. (Though more complicated arrangements are possible.) More people might join Abby and Ben. A large uploader syndicate would decrease the need to make frequent small BitCoin payments. How hard is this to implement? On Linux, the traffic shaping should be easy[1]; a simple service could let downloaders request a BitCoin deposit address from uploaders[2]; and the simple service would also poll the BitCoin daemon[3] to see which payments have been received and then move those IP addresses to the appropriate pool. Comments welcome. -Dave [1] Famous last words? Also, I have no idea how hard traffic shaping is on other platforms, especially Windows. [2] Perhaps the service should require incoming requests contain a hashcash token to reduce the chance of DoS attacks. You don't want some 12 year-old asking you to generate 10 billion BitCoin keypairs. [3] Though I'd love to see GavinAndresen's in-progress monitoraddress postback request implemented for this. |
|
|
|
We SHOULDN'T pay for little chunks. Just think how such micropayments would overload the entire bitcoin network. Read these fee rules especially the block size part. Thanks for the link. I hadn't read that before. It appears to me that the BitCoin network can't handle more than about 30,000 transactions an hour. I bet there's much more than 30,000 Bit Torrent downloads an hour most days, so even paying for big chunks--even paying for whole files!--can't persist for long. Transaction fees, when they appear, will probably motivate people to use different payment processors for small transactions. They might use centralized trusted third parties like FreeMoney suggests, but for something under government scrutiny like Bit Torrent, I think people will want to use a decentralized currency--something like BitCoin. The solution, I think, is to build support for multiple BitCoin networks into the BitCoin-enhanced Bit Torrent clients[1]. The main BitCoin network will be akin to gold; the next network might be akin to silver; the next, copper; etc... In the example story I gave, Abby would simply send a BitCoin address for each network she supported. Chrissy and Daniel would pay using networks which didn't charge transaction fees. Exchange rates would allow Abby to compare Chrissy and Daniel's contributions in absolute terms. -Dave [1] I agree with mizerydearia that this should be implemented as a plugin where possible. |
|
|
|
|
It occurred to me after I made my previous post that my example doesn't require three keypairs--the buyer could simply give a copy of the second keypair to the arbiter.
I'm not able to think of a another likely scenario where more than two keypairs are required.
Thank you anyway, -Dave
|
|
|
|
I can't believe I didn't find that in my search before posting. Thank you. As you say in the linked post, the escrow is implemented in software (running on the nodes, I presume), so in theory the network can support a transaction that requires n signatures, where n can be any number. Is this correct? If so, can the network also support transactions that require a majority of signatures (instead of all registered signatures)? For example, the buyer generates three keypairs--using one to initiate the transaction, saving one to release the funds, and distributing one to an arbiter trusted by both parties. Either the buyer or the arbiter could then release the funds. Thank you again, -Dave |
|
|
|
we [ought to] pay [for] relatively large pieces at once. But whom to pay then and how much? And when?
[...]
The only solution I see is to encrypt all chunks from each client with some key that only uploader knows.
When you seed on Bit Torrent today, you get no guarantee that the person you're sharing with will share with anyone else--yet the system works just fine. I think we can extend this hopeful principle to a payment system. Abby begins seeding a file to a swarm of two other people, Ben and Crissy. Abby's uses a BitCoin-enhanced Bit Torrent client which, when it makes the initial connection with a leech, sends a fresh Bit Coin address.[1] Ben doesn't use BitCoin, so his client ignores the extraneous BitCoin address and downloads like a regular leach. Crissy, on the other hand, also uses a BitCoin-enhanced client and she sets up her client to send 0.01 BTC for every MiB received. Her client notices Abby's BitCoin address and sends payments there in the ratio Crissy specified. After uploading her first MiB to Crissi, Abby's client notices the incoming payments and correctly attributes them to Crissy--and from then forward prioritizes uploads to Crissy. Now lets say another user enters the swarm--Daniel. Daniel uses a BitCoin-enhanced client too and he's in a big hurry to download the file, so he sets his client to pay 1 BTC for every MiB. Abby's client will soon notice Daniel's greater payments and will prioritize uploads to Daniel first and Crissy second; Crissy's client will also prioritize uploads to Daniel over Ben. In summary, BitCoin-enhanced Bit Torrent clients upload like normal Bit Torrent clients until they receive BTC; then they prioritize uploads to whichever client pays the best. How do they know who pays the best? They simply divide the total number of bytes uploaded to that person by the total number of BTC received from that person. (Later implementations may want to use a moving average to react quicker to changing conditions.) -Dave [1] The fresh BitCoin address is so the client can correctly attribute all incoming payments to their originator's Bit Torrent client. |
|
|
|
Summary: Giving BitCoin a decentralized escrow would give it an advantage over all other exchange mediums, which might increase its adoption rate. Details follow. For a decentralized currency, centralized escrows seem to be the norm for BitCoin today. An example: Alice wants to buy $5 USD worth of BitCoins from Bob, but neither Alice nor Bob fully trust the other, so they go to a site they both trust--say Mt. Gox. There they deposit their respective monies and there they have Mt. Gox make the exchange for them. No offense to Mt. Gox (a site I like), but can we do without its escrow service? An almost distributed alternative: - Charlie, a trusted third-party, generates a BitCoin private key.
- Charlie then uses the Unix command split to split the private key in half--giving one half to Alice and one half to Bob.
- Bob deposits $5 USD worth of BitCoins into the split BitCoin account;
- Alice verifies the transaction using the public block;
- Alice sends $5 USD to Bob by PayPal;
- Bob verifies the PayPal transaction;
- Bob sends Alice his half of the split private key so Alice can access the BitCoins he deposited earlier.
(For simplicity I omit part of the PayPal details like who pays the transaction fee and how long you should wait to avoid chargeback fraud. I also omit any incentive for Bob to perform the final step.) More advanced almost-distributed examples can be made if we substitute something more sophisticated for the Unix command split. For example: a Shamir's secret sharing scheme implementation like ssss[1]. A utility like ssss allows Alice and Bob to appoint an arbiter in case they get in a disagreement. The problem with all of this, of course, is that we must trust Charlie to not abuse the full copy of the private key he creates. The ideal solution would be for Alice and Bob to each generate half of the private key on their own. I don't fully understand the math used in modern keypairs, but I doubt this is possible with the current algorithm. Is there an alternative way for Alice and Bob to each acquire half of a private key without giving the whole key to any party? -Dave [1] See: http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing |
|
|
|
[...] say more than 10% disagree, the mod has the final vote (Kiba)
The funds are frozen until one outcome is chosen by people who represent 50% or more of the betting stake.
How do you prevent fraudsters from placing 90% of the bets? (50% in ribuck's example.) Provided you do that, how do you assure me that the people betting with me are not idiots easily duped? -Dave |
|
|
|
who [confirms the outcome of a scenario] and distributes the coins?
The simplest way is to let the participants confirm the outcome and have the site distribute the BTC. Here's how it works: Every scenario has an end date. After that date, all participants are asked to log in to their accounts and record whether they lost or won. As each loser confirms losing, the site divides among the winners that loser's contribution to the pool. A proportionate amount of the winners' contribution is also paid out to the winners, ensuring the pool maintains the same ratio of bets for and against the outcome that it had when betting stopped. But, you ask, what keeps the losers honest? On a pseudonymous site, each user account can have an associated feedback score which helps determine honest players. On an anonymous site, the winners can offer a partial refund to losers who pay their bets. For example: losers who confirm their loss will be refunded 5% of their bet. As long as the money is stored in the site account (so the losers can't use it), the losers' best interest will be to confirm their loss and retrieve the refund. This system minimizes demands on the site operator (hopefully keeping costs low) but also protects both parties from unforeseen events. For example, imagine a bet 10 years ago on "who will win the year 2000 U.S. presidential election?" Those losers who don't believe the reported outcome was fairly determined can refuse to pay their bets, or better yet, they can request a high refund rate. If the winners agree about the unfairness, they will offer the high refund rate. But, you complain, my money and my winnings will be subject to the whim of some sore loser! This is true, but a good site will let you sell you future share of the winnings on an open market. You'll receive money now and some entrepreneur will try to collect from the sore loser. -Dave |
|
|
|
|
