Bitcoin is revolutionary because it is decentralized, with no single point of control or failure. However, over the last six months or so it has become obvious to me that the rest of the world isn't set up to interact with a radically decentralized system like Bitcoin, and I think forming a not-for-profit organization will be a positive step towards Bitcoin's long-term success. I'm posting this to see if there is a consensus on what a Bitcoin Foundation should be. To get the conversation started, here are some functions I think a Bitcoin Foundation could perform: - Interact with the legal system, where a centralized entity is needed: for example, to hold the Bitcoin trademark, own/control the bitcoin.org domain name, etc.
- Act as a central library for accurate information about Bitcoin, so journalists and policymakers have an 'official' place to learn about Bitcoin.
- Collect donations to fund infrastructure necessary for Bitcoin's growth (organize regular developers' conferences or get-togethers maybe? pay for development of cross-implementation testing tools? pay core developers' salaries? create a certification/testing program for Bitcoin implementations? create a central clearinghouse for information about legal issues surrounding Bitcoin across the world?)
Other not-for-profit organizations that could be emulated: - The Anti-Phishing Working Group (the APWG's chairman, David Jevans http://en.wikipedia.org/wiki/David_Jevans, is willing to help make a Bitcoin Foundation happen).
- The Tor Project
- The Apache Software Foundation
Are there others that work well, or are there examples of what NOT to do? Assuming there is rough consensus that a Bitcoin Foundation is a good idea, I would like to get something imperfect up and running quickly, with the expectation that it will evolve over time. |
|
|
|
|
I think Casascius did the right thing.
He has no way of knowing how many people got the phishing email, and no other way of contacting people who might fall for the scam.
If you're upset because you have to poke the 'delete' button on your email one extra time... then I think you're overreacting.
|
|
|
|
There's nothing wrong with trading Bitcoins, just like there's nothing wrong with exchanging USD to EUR to buy a glass of wine.
Yes, but if you are spending a lot of time or effort trying to make money on an essentially unproductive activity then I think you should ask yourself if there's something else you could be doing that would be more effective at making the world a better place. I think a lot of buy-low-sell-high, there-is-always-a-bigger-fool, or high-frequency trading fits into the "isn't making the world a better place" category. If you're competing for a bigger slice of a fixed-sized pie, I think you should think hard about what you could do instead to make the pie bigger for everybody. Mmmm.... pie...... |
|
|
|
You might want to include a note in the instructions about this.
You == me? There's a sticky here about creating a pull request, it'd be most excellent if you could make you==you and fix the doc/readme-qt.rst file. I'll try hard to remember to mention this for the 0.5 release notes, but I'll warn you I'm really good at forgetting things. |
|
|
|
|
I don't know nuthin about error-detecting checksums, but I think the time it would take to implement it and argue about it would be better spent on more user-friendly, secure ways of making bitcoin payments. I haven't heard of even a single case of "I manually typed in a bitcoin address and the coins got lost because I made an undetected transposition error."
|
|
|
|
Why allow recursion? Is there a use-case for this?
Yes. Although there might be a way of accomplishing the same thing without recursion: Use case: Imagine we want, in the future, to support "this" OR "that" transactions. Where "this" and "that" are themselves possibly complex multisignature or escrow or whatever transactions. Most straightforward way might be a new standard transaction that looks like: DUP HASH160 <hash160> EQUAL
IF
OP_EVAL "evaluate the this"
ELSE
DUP HASH160 <hash160> EQUALVERIFY
OP_EVAL "... or evaluate the that"
ENDIF
So you'd redeem it by putting one script or the other on the stack (along with the signatures needed by the script). So.... maybe you want to recurse so that the IF/ELSE script is itself part of a standard, single-hash OP_EVAL, so you can use a newfangled bitcoin address to send to it. That would look like: scriptSig: <signatures> <this_or_that_script> <IF/ELSE script>
scriptPubKey: DUP HASH160 <hash of IF/ELSE script> EQUALVERIFY OP_EVAL
I am NOT proposing an IF/ELSE "this or that" standard script type; I think there is plenty of enough work to do to actually make secure wallets and in-the-chain escrow work. But supporting limited recursion for non-standard or future transactions seems easy and safe... (terminology footnote: calling scriptSig+scriptPubKey "transactions" isn't accurate, the transaction is the bigger thing, but I'm not sure what else to call them; I hope y'all follow what I'm saying) |
|
|
|
There have been a number of proposals that would make this more safe to deploy, e.g. using a flag in the coinbase to perform a majority vote of hashpower to decide the height to enable the feature. Someone obviously needs to talk to some of the bigger miners and see if they have other concerns that need to be addressed but I don't see why a hashpower vote isn't sufficient, since the feature is non-forking.
I pulled a Satoshi and decided to implement OP_EVAL to make sure it would actually work. https://github.com/gavinandresen/bitcoin-git/tree/op_evalNot ready for pulling, expect rebasing/tweaking/changing. But it is fully working on the testnet. (example transaction here) The code puts "OP_EVAL" in the coinbase of generated blocks, so the rest of the network can see how many miners support it. I gathered contact information for the top ten mining pools last week; when there is rough consensus on the details, I'll contact them to see if they have concerns and/or are willing to support OP_EVAL. I started writing up BIPs for the various pieces of OP_EVAL, I'll post them soon. |
|
|
|
Example possible BIPs: URL syntax for bitcoin payments New OP_EVAL scripting opcode for receiver-specifies-transaction New bitcoin address format to support OP_EVAL (I'm actually working on those two) Informational: Process for announcing/scheduling/implementing a potentially block-chain-splitting change. ----------- You can browse through the PEP's at http://www.python.org/dev/peps/ to get some idea of the kinds of things that might be good BIPs; changes to the on-the-wire protocol to make blockchain downloads faster would certainly be appropriate. |
|
|
|
Amir started the "get more formal about changes to bitcoin" ball rolling by creating BIP 0001, starting from the Python "PEP" / BitTorrent "BEP" processes. The idea is to use BIPs for changes that may or will affect every bitcoin implementation (not to use them for proposed changes to one particular implementation). I'd like to propose some minor changes to the process: - I propose that BIPs be wiki pages, with a social convention that the Author gets final word if any editing wars break out.
- If he's willing, I propose that Amir take the role of BIP editor.
- I think bitcoin is still too small to have a specialized "bitcoin-ideas" mailing list; I propose that new potential BIPs be discussed either here or on the bitcoin-dev mailing list.
|
|
|
|
|
What are you optimizing for? Ease of implementation? Wallet size?
Here's a naive implementation that I bet would work well in practice:
+ Sort potential inputs by priority (priority is #confirmations * amount)
+ Use the N highest-priority coins whose sum >= amount needed
If you want to optimize for fragmentation and/or paying of fees, then also do:
+ If the change transaction is larger than some threshold amount, then split it in half (or maybe split it into Y change outputs, each of which is about the size of the threshold amount).
+ If the change transaction is small and there are other small-valued/low-priority inputs available, add a few small-value inputs to merge them together.
You could also optimize for privacy (try to avoid using more than one input and/or always create multiple change outputs), or tweak the above rules to try to always avoid fees...
|
|
|
|
Good luck keeping your account open without a FinCEN ruling excluding you from liabilities regarding reporting the personal information of depositors...
Double-huh? You write your Mt.Gox account information on the deposit, Mt.Gox has all the information necessary to report to FinCen (because only upgraded Mt.Gox accounts can use the service) if required (if depositing more than whatever the daily/weekly FinCen requirements are, yada yada...). What's up with the attitude Matthew? More ways to purchase bitcoin is a good thing... |
|
|
|
Like i said, convince me as a merchant to use your payment system while all my business expenses are in fiat currency.
So... what would convince you? What if you could pay 10% of your expenses using bitcoin, and it cost you 1% less if you used bitcoin? There are lots of chicken-and-egg problems that bitcoin has to overcome to compete with the dollars or euros we're all using now; I see two paths to bitcoin's success: Maybe there are enough ideologically motivated people to form a self-sustaining economy. If even 1% of people find the idea of bitcoin attractive and started using it for 1% of their transactions that would still be huge. Or maybe one or more 'killer apps' for bitcoin will emerge, giving it a foothold in certain markets. Maybe it will never expand beyond those markets, or maybe it'll slowly grow beyond them because of lower cost and higher tech. If you're not excited by the idea of being an early adopter for what could be a massively influential idea, then you should probably come back in three or four years and either tell us "Told you it'd never work!" or join what should, by then, be a much more stable and easier-to-use system. |
|
|
|
Gavin, have you abandoned any effort to utilize Stefan's bitcoinjs/nodejs stuff for this testing framework?
I never started with bitcoinjs/nodejs, because I'm not a JavaScript programmer (and I'm too busy to take the time to learn). It would be lovely if somebody who is a JavaScript programmer decided to show me how easy it would be and took bitcoinjs/nodejs and created a really nice cross-implementation testing framework with a bunch of test chains. RE: Mike's point that creating full-difficulty test chains is a pain in the ass: I think that one-time pain is worthwhile, because I don't think we can count on every bitcoin implementor making it easy to run their implementation in a unit-test mode with super-low difficulty. And creating difficulty-1 blocks with a GPU is actually pretty darn quick... |
|
|
|
Update: Now I move coins to a special sendmany account before trying to sendmany but it still doesn't work. It wants to CONFIRM A TRANSACTION I SEND TO MYSELF before adding the balance.
Pass a 0 as the third argument to sendmany and it will send unconfirmed coins: sendmany <fromaccount> {address:amount,...} [minconf=1] [comment] |
|
|
|
|
Nice work!
That's almost exactly the direction I'm heading with the cross-platform testing framework I've been working on, although I was planning on storing blocks in JSON format and was planning on using Python's Twisted/Trial framework to feed the different chains to the implementations to see if they accept or reject them.
I got sidetracked by the 0.5 release and then sidetracked again because I couldn't resist experimenting with the "OP_EVAL" idea and multisignature bitcoin addresses...
|
|
|
|
|
Corrupting how? Did they install 0.5 and then downgrade (is it a backwards-compatibility issue)?
Did it get corrupted when they encrypted?
Anything interesting in their debug.log?
|
|
|
|
Is there some market based mechanism which will counter this behavior?
Thinking out loud: If miners (or other nodes) not relaying transactions starts to become an issue, "we" could write code to detect and discourage it. Detecting: the node says it is a full node but you get many fewer 'inv' messages from it compared to your other peers. Discouraging: you refuse to relay or build on any new-block messages that you get from that node. See https://github.com/gavinandresen/bitcoin-git/tree/discourageblocks for a framework for the 'discourage' part. |
|
|
|
|
I can't resist, the problem of how to bootstrap a new chain in the face of massive, hostile hashing power fascinates me.
CoinHunter, what will happen to SolidCoin if, God forbid, you get hit by a bus? What are the plans for the trusted CPF wallets? Do your heirs get control of them?
And what if SolidCoin is wildly successful-- so successful that each SC is worth 1,000 euros? Will somebody still need 1 million of them (so have to be a euro billionaire) to be trusted?
|
|
|
|
|
Show Posts
