On Tue, Sep 11, 2012 at 5:48 PM, Matthew Mitchell <matthewmitch...@godofgod.co.uk> wrote: > You wouldn't need to pipeline the requests, just place more than one > inventory vector in get data, right? Well my messages would save the space of > those inventory vectors. Instead of needing 36 byte inventory vectors for > each transaction and a var int, you would need two var ints only. And then > the transaction responses only need one header, so you save 24 bytes for each > transaction after the first. You could say that is a small benefit.
But you only need to request the transactions you don't have. Most of time you should already have almost all of the transactions. > Look at bittorrent. With bittorrent you don't download files from a single > peer all at once. You can fetch transactions from multiple peers with just a simple mechanism that gives you the headers plus the txn list. And if you want ArgumentAdSomethingElse, thats what bittorrent does too: the torrent file contains the list of block hashes, and you get it from one place. > Why wouldn't requesting minimum fees in the software work as is done > currently? Because there is no motivation not to set them to zero, if you don't someone else will. Right now the income from fees is hardly relevant, and the ability to drive more non-existant because there isn't enough load to create scarcity. > So what you essentially suggest is having bitcoin banks that maintain trust > through Open Transaction contracts which contains proof of agreement, > providing some legal protection? One wonders why have bitcoin at all then? > Why not have an elaborate e-money system between several banks using Open > Transactions? Because it can't resist inflation. You have to trust that the banks won't conspire to their mutual benefit to inflate the base currency. OT can make it so a 'bank' (which is really a distributed collection of nodes, not a single point of trust) can trivially prove how much "gold certificates" it has issued, but you also need to prove how much 'gold' exists and which keys hold it, and for that you need a _global_ consensus; which bitcoin provides... If you don't like >Bitcoin doesn't just contain proof of if something was done right or not, it >contains actual certainty that it will be done right. And how does Open >>Transactions prevent fractional reserve fraud? Well, Bitcoin gives you no certainty that any particular transaction will be confirmed at all, ever; so perhaps best not to overstate it too much. But yes, Bitcoin is great. ... but all that greatness depends on there being a way to fund enough computation so that attacks are too costly to be justified and that the cost of maintaining a system to fully validate the system's rules (e.g. that the miners aren't mining duplicate txns to create inflation for themselves) is low enough that it will naturally enormously distributed so that a conspiracy is effectively impossible. Otherwise everything consolidates down to a few meganodes and the attractive properties are all gone. OT's issuers can prove how much bitcoin they hold on the blockchain (by nothing more sophisticated than signmessage) and they can prove how many tokens they've issued against it. And I didn't mean to suggest OT as a unique solution. Another path is ripple, the idea of which is a sort of a p2p hawala where you have pairwise trust and debt. It can allow you to circulate around tokens between a community of users and only settle infrequently (as determined by your level of trust, the debt involved, and the cost of the bitcoin transaction) against bitcoin. > I suppose when people consider bitcoin banks, they will consider bitcoin > being useless. They already exist, in crappy centralized form— e.g. look at mtgox codes and user to user instant transfers; and bitcoin isn't useless. Plus some extra system of some kind is the _only_ way to securely irreversible transactions which are reliably fast, so it's not like there is any real prospect of using bitcoin directly for all kinds of uses at scale. (yes, blocks are 'only' 10 minutes apart on average, but if you care about fast, you care about e.g. the 99% not the average) > As far as I see it, if bitcoin won't scale, then it's worth looking at > something different to bitcoin that will scale. Bitcoin scales fine. It is not a singular replacement for everything you can imagine it being a replacement for, however, or at least not a good replacement. The fact that you could conceivably make it directly scale up to handle e.g. the volume of all the credit network doesn't make that a good idea. It would still be a very poor replacement for a credit network (slow transactions; which can't be fixed by tweaking some parameters, the bitcoin blockchain consensus algorithm has infinite convergence time when the block time falls below the hash-power-weighed latency), and that kind of scaling would absolutely ruin the decentralization, making it so only large states and megabanks could run full nodes, and even at that level it couldn't match the worldwide volume of cash transactions or 'internal' money transactions (like money moving around on all the poker tables in the world). It's like someone made the mistake of saying the floor wax is edible (linseed oil) and now you complain that its a crappy desert topping. :P Maybe people will ultimately agree to raise the block sizes, but I expect and hope that they'll only do so when it is entirely uncontroversial that doing so won't significantly degrade the decentralization (certainly not the case today: a large portion of the network appears to have trouble keeping up with large blocks right now, though upcoming software improvements will help enormously), or the mining economics. And yes, of course, you schedule the change for the future, but as you note that it doesn't solve the problem of people opposing it. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
