I think it is very premature to try and promote heavily without more of the basic building blocks available to the average end-user or the average merchant. Sure some nerds and geeks can figure it out eventually, but so what?
+1 |
|
|
|
Are there any hard limits of to how far the daemon can scale or is this limited by the underlying hardware?
No hard limits, but the bitcoind "accounts" code hasn't been optimized for that. For example, computing an account's balance loops through all transactions in the wallet, so will take an increasing amount of time the more transactions you have in the wallet. |
|
|
|
|
I got a copy, too. If you use gmail, use the 'Report phishing' function (in the Reply drop-down menu).
|
|
|
|
Please also enable the non-address versions. Like:
2 KeyA KeyB 2 OP_CHECKMULTISIG
1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG
Those are "Proposal 1" -- enabling all the 'plain-old' OP_CHECKMULTISIG transactions. groffer reports finding a bug in CHECKMULTISIG (pops too many items off the stack), which makes me wonder if it would be better to avoid it. For small n, using CHECKSIG multiple times is straightforward and doesn't make the transactions much larger. The (a and b) OR c transaction with public keys instead of addresses isn't in the proposal, but for consistency's sake I agree it should be. |
|
|
|
My worry is that we'll schedule a blockchain split 6 months from now, and between now and then somebody implements a secure, way-cool, everybody-decides-to-use, way to use your email address as a bitcoin address. So my receiving address is ' gavinandresen@gmail.com' and suddenly all the arguing over length of the bitcoin addresses used behind the scenes was just a huge waste of time. I'm as guilty of doing stuff like that as the next geek-- I can get so focused on one little bit of a problem I don't even realize solving a larger problem makes the whole issue go away. Slap me upside the head if you see me going down that path... |
|
|
|
|
Phew. Ok, I feel better; consensus seems to be that enabling some or all of the proposed 'new standard' transactions is a good idea.
All the rest (new address format? send to old addresses and immediately resend? etc etc etc) can be argued to death later.
|
|
|
|
Here is an idea: why not just modify the OP_CHECKSIG (which currently checks a single signature) so it itself supported multiple signatures that could be joined with logic?
Because I want to enable these features reasonably soon, and modifying the way CHECKSIG works means a blockchain fork for clients that haven't upgraded. Which means giving at least 6 months notice to give everybody time to upgrade their clients. At some point that will make sense, but with what I'm proposing it is not necessary. When SHA3 is finalized or a weakness is found in ECDSA or SHA256 maybe it'll be time to do that... |
|
|
|
The unfortunate thing about this construction is that the emergency key c, kept offline and hopefully never used is likely to be constant over a very long period of time. This results in a dramatic loss of transaction anonymity.
Clients could make c the base for a deterministic key; derive a series of keys from c, and use them in subsequent transactions. (given full public key for c, you can derive a series of public keys without having the private key) Same could be done for the 'wallet protection service' key b -- every time you use b, contact the protection service and ask for a b' derived deterministically from b. Then b'', b''', etc... |
|
|
|
I don't see why it's necessary to support addresses for backup and secure-device transactions. Bitcoin can remember the public keys before they are exported to the backup or device. With an additional device: 2 KeyA KeyB 2 OP_CHECKMULTISIG KeyA is a local key known by Bitcoin. KeyB is probably remembered from previous use; if not, it can be transferred in a QR code without much trouble (~90 base64 characters is fine). The multi-device use-case I'm imagining: I sign up with Acme Bitcoin Security Solutions, Inc. They give me a WalletProtection public key (or bitcoin address, doesn't matter) and a unique-for-me URL. I put the address/pubkey into my bitcoin client as "Second factor off-device Send Authentication." Or something. (ABBS also sends me the private key in the mail and tells me to keep it safe in case they go out of business) Now I want all coins sent to me to require signatures from keys in my wallet AND the ABBS key to spend. What bitcoin address do I give to people so that all coins going into my wallet have that property? If it is raw CHECKMULTISIG, then I need to give out addresses containing 2 full public keys. Which would be 186 characters in base58 and look something like this: LeFKX5Uhue9B4bVNqFouRdH9xyJ4uVksV16Gc3v5Kov6SEtyUmKmF3j582VHcmhKGEfBXvrft6SHAq4 SQPw5kbGryZj4aGqZKGFSPsotRJvrmQXCT8qZ2LZd3KyxFLDt1rsBx2uisukHPvBnyCpbyVdgNhyQYn z3Cf4oakK9Rm6oxFHwjHxHnnbdW3 Using 20-byte hashes and the more complicated 2-of-2 transaction i'm proposing, the address is a more reasonable 61 chars: 2SEe6qhJ11baZfpk9qXt3gfz3qAgFj4BMc2FXh9ojoBoLU4GAhft1hJAb5TAK |
|
|
|
|
You're right, I think even without blockexplorer Satoshi would've added the IsStandard() check. There were a series of "oops, didn't think of that" moments that pushed him to disable a bunch, tighten up some requirements on existing opcodes, and add IsStandard().
In general, I believe in "whitelisting" instead of "blacklisting" to try to prevent harm. Enable functionality that you can prove (or convince yourself beyond a reasonable doubt) will not cause problems. I'm strongly influenced from watching web content systems that fail repeatedly trying to detect malicious HTML or CSS.
RE: allow non-standard transactions but give them a very low priority so they take a very long time to confirm: I like that idea. I'll have to think a little more about possible unintended consequences (will they tend to fill up transaction memory pools and crowd out low-priority standard transactions? Do they need their own memory-limited pool? etc)
The intent was always to relax the rules when SPV/headers-only mode was implemented and non-mining clients didn't need to download the entire block chain. However, nobody tackled that work (it is on my TODO list, right after I tackle some testing framework work).
|
|
|
|
Sunday at the bitcoin conference I led a little brainstorming session on extending the set of 'standard' transaction types, and I've been picking people's brains via email and IRC chat (and pull request comments) to work through the details. My motivation for wanting to do this NOW is because it will allow features like: + Multi-device confirmation of spends, so if your computer is infected by a trojan it cannot spend all of your coins. + Master-key emergency backup, so if you lose your wallet (and all of its backups) you can get the master key from your safe deposit box and recover all of your coins It will also enable third-party escrow and some other nifty features that aren't as important to me. The first step in doing all of these things is to work out the lowest-level transaction format and to allow those transactions to be relayed and included in blocks. That is ALL I am proposing right now (actually implementing something like multi-device spend confirmation will require a little protocol for the devices to communicate, a new kind of bitcoin address that people will send into, etc etc etc). Working out a common way of doing (for example) 1-of-2-keys-required transactions will make it much easier for sites like blockexplorer to display them intelligently, and will generally make life happier for anybody writing tools that look at the blockchain. I'd rather not have this turn into a "lets get rid of the IsStandard() check" or "lets re-enable a bunch of currently disabled opcodes", so if you want to talk about that start a new thread. Current draft proposal is here: https://gist.github.com/39158239e36f6af69d6f |
|
|
|
|
I've been working on a proposal to enable {1,2}-of-{1,2,3} signatures-required as standard transaction types.
I'll start another thread with more information...
|
|
|
|
|
I enjoyed the conference, and I usually hate conferences.
Apologies to everybody who I met and whose name I've already forgotten. My secret super-power is forgetting names.
And congratulations and a big Thank You to Bruce and company for organizing and making it happen!
|
|
|
|
You're talking about the developers intentionally revoking previously-valid transactions by central fiat - and they can't just revoke the ones involved in the double-spend, they have to revoke all of them.
Why couldn't the-collective-we only revoke the double-spends (and subsequent txns that depended on them) ? A hard-coded list of invalid txids wouldn't be hard to insert into the is-valid-transaction checks, and that along with a blockchain checkpoint would work just fine. Valid transactions on the bad chain would move to the new chain (actually, they'd already be on the non-attacker chain, since the miners on both sides of the block split would have included them). |
|
|
|
Would you be interested in nightly builds for DragonFly BSD and OpenBSD?
Yes, would you be interested in building? |
|
|
|
It doesn't make sense as long as people still follow the rule of "build off of whichever version of a block you see first", but if some people stop doing that then some possibilities open up.
I think this is not true. I think the rule is: "hash on top of the longest chain (measured in work, not in blocks)". Yes, but if two blocks are found with the same difficulty then they are considered equal work-wise (even if one has a smaller hash value-- the "Bits" field in the block is used to compute chain work, not the block hash). If there are several valid tip-of-block-chain choices all of which have the same work, then miners are free to build off whichever one they like. The rule everybody (I think!) is using now is "build off the one seen first." |
|
|
|
|
Transactions have multiple inputs and outputs.
If you have 0.5BTC inputs, then 50 of them will be bundled together and a transaction with 50 inputs and one output will be created.
... but that's not what will actually happen. A 50-input-transaction will be over the "small enough to be free" transaction size limit, so 51 will be bundled together and a transaction with 51 inputs and two outputs (one to the destination, one back to you for any change leftover after paying the transaction fee) will be created.
There is no ledger, there are just transactions with inputs and outputs. Your bitcoin balance is the sum of all the outputs to addresses that you own that haven't yet been used as input to another transaction.
|
|
|
|
|
+1 for vector76's hypothesis.
If mybitcoin was running bitcoin behind Tor, and had just one connection (through a Tor exit node) to the rest of the bitcoin network, then they'd be particularly susceptible to this 1-confirmation attack.
|
|
|
|
|
Show Posts
