If demand is there, I like Stefan Thomas' idea of lifting the block size limit, and scaling the network up: Processing more transactions means that hashing is a smaller part of the
overall cost for miners. For example, paying for 50 BTC worth of hashing
per block costs 0.05 BTC per tx at 1000 tx/block, but only 0.0005 BTC at
100000 tx/block.
Number of transactions is a lever that lets us have lower fees and more
network security at the same time. Like Greg correctly pointed out, this
is not worth having if we have to sacrifice decentralization. But if we
don't, it becomes a no-brainer.
Just because I think the inflation schedule should be thought of as set in stone for psychological reasons, I'm hoping for something more along the lines of a block discouraging scheme https://en.bitcoin.it/wiki/Discouraged_block to enforce a minimum tx fee, or Mike Hearn's assurance contract idea https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts to directly fund hashing. If the fraction of miners discouraging blocks that undercut a minimum fee is large enough, it would be uneconomical to go against them. And joining this "cartel" would be The Right Thing To Do for a miner who has an interest in health of the network. |
|
|
|
|
I'm thinking the printable bill standard should be such that the qr code containing the private key also contains a change address specified at the time of the bill's creation. Then there'd be no need to manually mess around with change at all at the point of sale. The spender can also more easily avoid address reuse, since the bill creation program would by default just grab a new address from the wallet for change.
|
|
|
|
|
This sub-forum really makes me appreciate the value of political frontiers.
|
|
|
|
My take on it: - Uranium has weapons applications, thorium doesn't (means government has a major incentive to subsidize uranium over thorium).
- Government subsidizing uranium over thorium crowds out R&D for a thorium industry.
- If there's already a mature uranium industry in place (a lot of inputs are required to get the final product), why bother spending to develop thorium?
- Coal and natural gas are much cheaper.
Also, libertarians aren't the only ones prone to wearing ideological blinders. |
|
|
|
|
Tried that already with no luck...
|
|
|
|
I keep getting this error when trying to update on Ubuntu 12.04: GPG error: http://ppa.launchpad.net precise Release: The following signatures were invalid: BADSIG D46F45428842CE5E Launchpad PPA for Bitcoin Any help is much appreciated! |
|
|
|
The only difference is that with Bitcoin nobody has the ability to offer unlimited bailouts to cover unbacked credit.
Yes, this is the crucial difference: FRB + elastic money is a deadly combination. FRB with gold backed money was common practice so there is no way bitcoin can be immune to excessive FRB. However, with gold, bankers were using the difficulty of moving around gold inventory as a lame excuse for opacity and fraud. Conversely, a bitcoin bank could not pretend it cannot deliver bitcoins: that's one of the two reasons a bitcoin banking system will be safer and less prone to excess than the current "debt based" banking system. The other reason is that a bitcoin banking system rides on top of a p2p system: one can always fall back to being one's own bank. My hope is that something like Mike Hearn's 'Distributed bond markets and pay-to-policy outputs' https://bitcointalk.org/index.php?topic=92421.0 will turn the bank-as-middleman-in-lending into dead weight/an unnecessary liability, and thus prevent widespread FRB from arising in the first place. |
|
|
|
I'd say avoid any rule changes by forgetting about changing bitcoin's reward scheme to incentivise miners to hash away at the balance chain, since updating the ledger once a week is practically free, merged mining makes the hashing cost nothing extra, and by participating they'll be enabling significant disk space savings for themselves going forward. Plenty of incentive there already IMO. Then it can be gradually adopted by miners without controversy, and once enough of them are on board, as measured by the balance chain block rate, other clients can feel free to start trusting it. Also, instead of having a simple tx tree, maybe use something like this structure instead: https://bitcointalk.org/index.php?topic=52859.msg885838#msg885838. I'm an amateur here too, though, so maybe there are lots of problems with this we're not seeing. |
|
|
|
Was this something he wrote when he opposed the US Civil War?
Was that meant to be some kind of dig? Look Spooner up on wikipedia. He was a great guy but the US Civil War exposed a lot of problems with his logic. He felt that slavery was wrong and should be abolished. He felt the Lincoln was pushing the south for reasons that were totally immoral. He felt that the slave owners had a right to secede rather than lose their property. He was honest enough to put all this in writing. Spooner never got over the criminal law question. 99% of people feel that property is a legal right and that if you take it without consent and without legal authority, you deserve to go to jail. 1% do not agree - what gives the 99% the right to jail the 1%? That reasonable people can't be opposed to the US Civil War in your world view makes me not take you seriously. |
|
|
|
Was this something he wrote when he opposed the US Civil War?
Was that meant to be some kind of dig? |
|
|
|
Gweedo, you sound rabid  Relax, we're just throwing out ideas. More uses for bitcoin is good for the "community" IMHO. On a separate site is fine, too. Nobody wants a mess of a site that tries to do everything for everyone. |
|
|
|
Dude honestly your looking for so many features that are only beneficial to you.</snip>
 why you hate cooks? And tutors? They couldn't have students stumbling on all the porn either... |
|
|
|
In your first post it was automation which if it was automated would then need the user to always put in their bitcoin address to just view and some people may not like that. Also how would the broadcaster know who address is whose? This would cause so many fights and angry people that would just stop coming to the site. The site is simple if you like the broadcaster, or what they are doing on cam. You tip, your over complexing this simple idea.
Eh? I figured the broadcaster would just give the site a batch of addresses, and the site's software would apportion them to the individual viewers, granting access once payment was received. No automation is fine, though, I was just curious. It would hurt the tutor as well  Believe me anytime there is a "pay to view thing" people will never pay, as much as if they feel they got things out of the lesson. I know especially for a tutor I wouldn't pay until i figured out if their teaching style helped me learn or not. Well reputation/word of mouth would probably help here. The tutors I know get a lot of their students that way. None that I know of work by donation either, though, but I'd rather not have this coversation here For screencasting get manycam for windows/mac or if your on mac OSX get camtwist problem sovled.
Thanks! |
|
|
|
This may be feature creep territory here, but to make this really suitable for tutoring, it'd be nice if the viewers could request that the broadcaster pull up their screencast to play in a window beside theirs, so that communications can become 2-way (or more). Would that be possible, or is it too far out of scope? Edit: I know there's the chat, but that's not too suitable for entering math equations... Further edit: Maybe math is too niche for this feature |
|
|
|
Also he doesn't want to handle any bitcoin transactions, that is again a vision of the site, the bitcoins go directly to the users.
He wouldn't. The broadcaster would be handing out their own addresses. So that automation would be worthless and just hurt the cam girl.
Or the tutor, which is what I currently have in mind Which brings me to my next question: is screencasting in the works? |
|
|
|
|
I just checked to see if the broadcaster can boot people from their channel and heard it was in the works.
Was thinking this could be used as a way for broadcasters to enforce "pay to stay" where they'd give out unique bitcoin addresses to incoming viewers that they must pay to in order to stay. Anything like this, but more automated, in the works?
Could they also have the option to close the channel to new visitors?
|
|
|
|
I have some requests that might improve the btc side of cam4btc: - URI and QR code support
- show the amount received by the posted address since the beginning of the broadcast
- include 0-confirmation sends in this
- detect and filter double spends from this (can't do anything about finney attacks, but they're tips, so it's probably not a big deal)
|
|
|
|
Thanks for the excellent responses! Still it is a totally non-issue. Block size is 500 KB. Average tx is ~ 500 bytes. So the current block size is good for ~180K daily tx. We are a small fraction of that. If (due to economic pressure) some of the spam (satoshi dice, miner's taking 2 bitcent payouts, etc) was reduced we likely wouldn't even be 2K tx.
Ah, didn't realize so much of it was spam that wouldn't occur if transactions weren't basically free. Still, though, 180K transactions/day is only ~2tps, or 0.1% of Visa, so hopefully this issue won't arise too far into the future Another reason I can think to keep the limit is I believe the client software that talks with the tx servers would be engaging in real-time audits (for OT, anyway), and would thus require running a bitcoin client (something the average PC would be able to do because of the block size limit). While smart phones would use SPV (or the merkle tree of open transactions gmaxwell just mentioned) to audit, there would still be a lot more fully verifying clients out there. This is important, I think, because Lightweight clients can't efficiently calculate the size of the coinbase for a block without downloading the whole block and then downloading the dependencies of every transaction in that block, along with the Merkle branches linking them to the relevant block headers (which may also need to be fetched because I think in future lightweight clients will throw away very old headers).
This means the inflation schedule can be much better enforced by staying decentralized, correct? |
|
|
|
|
Just thinking aloud here...
I'm inclined to agree with gmaxwell that an off-blockchain transaction infrastructure is the answer. Seems like it would be much cheaper, and more convenient and private/anonymous, anyway. And with multisig/P2SH, it seems like it could be very secure against operators running off with the bitcoins people have bailed onto the tx servers.
OTOH, if this infrastructure isn't available when the block size limit is bumped up against and transactions start getting delayed and expensive, I doubt developers will be able to resist demands to increase the limit.
If it's not ready in time, could we ever revert back when it is, or would there be kind of a ratchet effect to this?
|
|
|
|
|
Show Posts
