|
Those 0.002 bitcoins cannot be redeemed, because there is no input that will make that script valid (because there are no OP_ENDIF opcodes in there to match the OP_IFDUP/OP_IF opcodes).
|
|
|
|
|
If you're using multisig to secure your wallet, then I think backup could be "free" ; all the involved multisig keys could be derived predictably from singlesig keys that you'll already need to backup. Disaster recovery from a lost wallet would mean importing all the backed up singlesig keys, then deriving (say) the first 1000 multisig ScriptSigs that would have been derived from those keys and scanning the blockchain for transactions involving those (and, hand-wave, hand-wave, doing something smart to derive more than 1000 in case it looks like more than 1000 were used). (or, in other words: what kjj said)
If you're using multisig for escrow involving other people... then the escrow transaction has to be recorded and backed up, including all the keys involved. In that case I'm pretty sure you'll want to record and backup other information about the escrow-- like "100 BTC escrow to my cousin Bob; release them if he's still not smoking on June 1."
Backup should be part of the user experience design for the escrow function; for example, I think a lot of escrows will an associated date, so the client should store the escrow transaction id AND the public keys involved in the escrow AND a "remind me to do something on June 1" AND (maybe) a link to my Address Book entry for Bob so I can call him on June 1. For me, I think the best way to backup that kind of escrow information would be for the client to send me an email containing all of that stuff in a standardized mini-file-format; I'll let gmail archive it and that would be my emergency backup.
So, emergency recovery of a lost wallet would then be:
1. Recover all private keys from paper backup (or whatever the singlesig backup solution is).
2. Re-import all escrows that involve other people from email archive.
RE: Bytecoin and "OR BACKUP_KEY" : In either the OP_EVAL or the BIP16 case you need a new type of 'standard' transaction (and bitcoin address) to make that work.
|
|
|
|
Possible fix for GUI freezing on Windows after a crash:
I started an in depth investigation and used Sysinternals Procmon.exe for this. I wanted to know which files or registry keys the client processes and one folder came to my attention.
Nice! Thank you very much for looking deeply into this; it looks like the inter-process-communication doo-hickey bitcoin uses to handle bitcoin: URLs was left behind when you blue-screened, and that's making startup fail the next time around. |
|
|
|
bummer. i'm running ubuntu 11.10, nothing special, 64bit. downloaded rc1 into ~/tmp and did this: ~/tmp$ ./bitcoin-0.6.0rc2-linux/bin/64/bitcoin-qt
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in Runaway exception
The dreaded DB_RUNRECOVERY... that's usually caused by running an older version of BDB (0.6 is compiled against BDB 4.8) on a datadir written with a newer version of BDB. Recovery isn't hard; just delete the .bitcoin/database/log.000* file(s) and any .bitcoin/__db*.log files. Were you previously running a self-compiled version of Bitcoin? From http://subversion.apache.org/faq.html#divining-bdb-version : cd ~/.bitcoin/database
od -j12 -N8 -tx4 log.000* ... will show what version of BDB the log files were written with. |
|
|
|
|
FYI:
The Bitcoin Faucet bitcoind's are both running on a Linode VPS, which was mysteriously restarted 14 hours ago. The 5 bitcoins in the main-net Faucet's wallet were stolen, also; I'll shutdown the Faucet website, do NOT donate any coins to the Faucet donation address, it is controlled by the thief.
Transaction ID: 14350f6f2bda8f4220f5b5e11022ab126a4b178e5c4fca38c6e0deb242c40c5f
... if you want to start watching where the coins end up.
|
|
|
|
Windows, Linux and Mac binaries for 0.6rc2 are up at: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/Please use github to report bugs: https://github.com/bitcoin/bitcoin/issuesNote that there were a few "release candidate 1 doesn't work on Windows" bug reports that, as far as I know, have not been fixed. We need some good Qt-on-Windows developers to help out, none of the current core developers use Windows as our primary development platform. A lot of bug-fixing happened between release candidate 1 and release candidate 2, but we did also sneak in one major new feature that was long overdue: a Backup Wallet menu entry. Be aware: the 0.6 release will create wallet.dat files that will not work with older releases, so you should back-up your wallet before running in case you need to revert back to an older release. 0.6 doesn't mark the wallet as backwards-incompatible until a new 'compressed' keypool key is added, so until you do something that generates a new key the wallet will stay compatible. Compressed keys will benefit everybody by using less network bandwidth, allowing more transactions to fit into each block, and making the blockchain smaller than it would otherwise be. Even a little time testing helps a lot; if you do can do some testing please reply in this thread with a message like "Bitcoin-Qt and bitcoind both worked nicely for me on my OS 10.6.8 Mac, running on -testnet." |
|
|
|
From the arimaa whitepaper: Although there can be multiple registrars to choose from an individual
or organization can maintain only one effective account with only one registrar. Right-- good luck with that! Any system that relies on Wise, Efficient and Effective Bureaucracies to decide hard questions like "are these 400 accounts really one scammer trying to get more than their fair share" are doomed to fail if they ever get large enough to attract the attention of scammers. If you have a really good automated way of telling the scammers from real people that doesn't require them sending in a DNA sample or body part, please let me know. I could use a good solution for the Bitcoin Faucet. |
|
|
|
This would replace the existing JSON-RPC getmemorypool command? getmemorypool [data]
If [data] is not specified, returns data needed to construct a block to work on:
"version" : block version
"previousblockhash" : hash of current highest block
"transactions" : contents of non-coinbase transactions that should be included in the next block
"coinbasevalue" : maximum allowable input to coinbase transaction, including the generation award and transaction fees
"coinbaseflags" : data that should be included in coinbase so support for new features can be judged
"time" : timestamp appropriate for next block
"mintime" : minimum timestamp appropriate for next block
"curtime" : current timestamp
"bits" : compressed target of next block
If [data] is specified, tries to solve the block and returns true if it was successful.
And a meta-question: are there any other implementations that will be supporting external mining via JSON-RPC soon? There's no reason to go through the whole BIP process to make a change or improvement to one implementation. |
|
|
|
I'll talk a little about what bitcoin allows, and some of the cool projects as a result, GLBSE, bitdrop and SilkRoad.
Do you have to talk about those three projects? How about Bitcoin-Charity.com or CoinWorker.com for projects that aren't so potentially controversial? |
|
|
|
Doesn't gavinandresen have a protocol fuzzer?
https://github.com/gavinandresen/bitcoin-git/tree/fuzzer... but it is pretty narrowly targeted at stress-testing the transaction validity code. Last year at the NYC conference I mentioned that I would really like to see somebody who knows a lot more about network simulation than I do develop tools to help test proposed protocol changes, simulate Sybil or DoS attacks, etc. I'd still really like to see that... |
|
|
|
|
eleuthria is right.
The bad-for-not-upgraded-miners scenario is:
+ Somebody gets a valid BIP16 transaction into the chain.
+ They then spend that transaction by broadcasting a 'standard', non-BIP16 transaction, BUT they create a signature for the BIP16 part that old miners consider valid, new miners consider invalid.
+ The old miners will add that 'poisonous' transaction to their memory pool and if they include it in the blocks they mine then those blocks will be rejected by most of the network.
makomk pointed out a while ago that I hadn't noticed that old miners will accept spends of half-valid BIP16 transactions, because the old code doesn't check to see if a transaction is spending a non-standard input. He's right; one of the changes in the 0.6 release is an AreInputsStandard() method, to make upgrading smoother next time.
Executive summary: if you are a p2pool or solo miner you should upgrade before the switchover date (April 1, if all goes well) or there is a good chance you'll produce nothing but orphan blocks. I welcome suggestions on how to effectively get that message out to the community.
|
|
|
|
|
Reposting from the bitcoin-development mailing list:
Mining support for BIP 16 is still under 50%, and won't possibly be over 50% by March 1. Which means we need a new evaluation/switchover date:
Re-evaluate support: March 15'th
Target switchover: April 1
If you're already supporting BIP16, restart bitcoind with the argument:
-paytoscripthashtime=1333238400
... to delay switchover until April 1.
Hopefully this will be the last delay; Tycho has told me that the deepbit pool will support BIP16 as soon as he's able to merge and test the changes, which will put support at well over 55%.
If you are a solo or p2pool miner you are strongly encouraged to upgrade bitcoind/Bitcoin-Qt in the next month; if you don't, you risk creating orphan blocks that the rest of the network will reject (and that risk will rapidly become greater over time as BIP16 transactions start to appear in the main block chain and get relayed across the network).
|
|
|
|
Yes, the problem with BIP 16 is obvious and I and others have discussed it enough. Read the BIP, or at least genjix's summary. In my humble opinion, this kind of trash talk against BIP 16 is bad for Bitcoin. The poll in this thread says the community prefers BIP 16. The chart on the bitcoin wiki says the core developers prefer BIP 16. And the actions of the big mining pools and independent miners says that they overwhelmingly prefer BIP 16. Luke, I'd be delighted to add Eligius to the list of pools that are supporting BIP 16 in my signature. |
|
|
|
what will you do if the bitcoin price rises by a factor of 100? your domains will cost 100 times what they did before.
I think you might be conflating two costs: Cost #1 is the cost to get a bunch of domain transactions accepted. I believe pent's proposal is based on additional difficulty, which will be independent of the bitcoin price. In other words, if bitcoin difficulty is 100, then maybe you need to solve a difficulty 110 block to get your additional DIANNA data accepted by the other DIANNA nodes who are maintaining the key:value database. If bitcoin difficulty rises to 1 million, then you need to solve a difficulty 1-million-and-ten block to get your data accepted. The additional difficulty factor should be set by the DIANNA nodes based on their ability to process/store data. More thinking is needed about what that function looks like (it reminds me of the bitcoin fee algorithm; it's trying to solve a similar problem, preventing spam/abuse but allowing as many transactions as possible for the lowest possible price). Then there's a completely separate Cost #2, which will be higher than cost #1, that is the payment that miners (aka registrars) will charge to handle domain transactions (and do the work of bundling them up, creating some sort of summary hash, and getting that hash into the bitcoin block chain). That's just a free market. (I'm completely ignoring Cost #3, which is the "what if I want to purchase an existing domain" price, and is whatever the owner is willing to sell it for.) |
|
|
|
I think i got it Gavin.
Registar = bitcoin mining pool for simple case.
Yes Client sends X BTC to mining pool in a special marked transaction. He signs domain name with domain private key and put it to Script with following OP_DROP for exmple.
Yes, you could do it that way, re-using Bitcoin's Script system for signatures. I suppose it might be useful to require m-of-n signatures for a domain to be transferred to somebody else. I wouldn't make them full-fledged Transactions, though (multiple "inputs" to a domain renewal or transfer doesn't really make sense, for example). Then he goes to bitcoin pool, give it:
- initial transaction_id
- domain name
- domain public key
and asks to register a domain.
Pool gather such domains in a DIANNA block (performing validation and d/spend checks) and tries to find its hash with merged mining of parent bitcoin block. But with bitcoin block difficulty and difficulty correction in my formula.
After success, pool pushes DIANNA block in diana network.
Dianna network has all required data to check this block:
- It has referenced bitcoin transactions
- It has domain names and pubkeys to make sure those a signed by domain owner
- It has a hash of parent Bitcoin block, so it can see its difficulty and number of bounties
- So it can calculate a valid difficulty target to match dianna's block hash
So the grounds of putting domain in DIANNA's chain is the initial bitcoin payment. DIANNA will refuse domain transs without corresponding payemnts.
Abuse activity of mining pools here is not profitable. If pool will send initial transaction from his address to another his address, this anyway will increase the dianna's block difficulty.
In this scheme DIANNA isn't vulnerable to 51% attack, as its basic difficulty and hashing power will be taken from bitcoin.
Am I right?
Yes, I think that's right, although I was imagining that the DIANNA and bitcoin difficulties would be kept separate and not combined. Combining them is probably a better idea (if you find any blocks that satisfy the bitcoin difficulty but not the DIANNA+bitcoin difficulty you can still announce them on the bitcoin network and get the block reward). RE: what is the incentive for maintaining the DHT: the registrars/mining pools would, I think, be the primary maintainers of the DHT and their incentive to maintaining it is the registration fees that they charge. I haven't thought deeply about possible attacks; if a DHT is used then you have to defend against Sybil attacks (you must have some way of checking to make sure the data you get from the DHT is valid, e.g. have the DHT nodes return a Merkle branch down to the data they're returning that you can verify hashes to the correct Merkle root). |
|
|
|
I do not understand why in the basis of a decentralized system, you are going to add a centralized registrar?
I should have made it clear: I imagine there will be an arbitrary number of registrars. They will compete to provide the best service (fastest updates of the DNS database, lowest prices, etc). If you were willing to do the proof-of-work and insert your own updates into the bitcoin block chain then you could be your own registrar (I assume most people won't be willing to setup the necessary software, run it, etc. just to register a couple of domain names). |
|
|
|
Many people ask, how much domain will cost? Lets give a formula for people.
I really like your idea of scaling up difficulty based on the number of domain operations in a block to prevent the key:value database from growing arbitrarily big. It seems to me that should be enough to make domain operation pricing correct; I don't see why there needs to be a block reward or fees, I assume the registrars will charge whatever they need to charge to make a profit, and I would strongly encourage you to avoid making the DNS system yet-another-currency. I'd like to use dollars or euros or bitcoins (preferably bitcoins) to pay for my domain names, please. I imagine a system something like: + I give some money to a registrar, and ask them to register/renew/transfer 'gavinandresen.dianna' + The registrar makes sure the register/renew/transfer operation is valid + The registrar bundles up a bunch of register/renew/transfer operations and then asks/pays a Bitcoin miner to merge-mine that hash to securely timestamp those changes + After they're timestamped, the registrar asks that all of those record changes be inserted into a shared distributed hash table, providing the DIANNA proof-of-work and the bitcoin block hash. + The nodes maintaining the shared DHT make sure the records have the right DIANNA proof-of-work, that the bitcoin block is valid, and that the changes aren't over-ridden by a later bitcoin block, and then update the records. |
|
|
|
If I have 50 BTC on my address and I want to send 10 BTS to another address then the rest of 50 BTC = 40 BTC will sent to a new generated address.
I know that was integrated to make the flow more anonymous.
Is there a possibilty to deactivate this function?
Because I need a clean simple transaction history where I and other users can check it.
I've got a "noprivacy" branch of bitcoin that I use for the Faucet: https://github.com/gavinandresen/bitcoin-git/tree/noprivacyInstead of creating a new address for change, it uses one of the input's addresses. It works nicely if your entire bitcoin balance is one "account", but will fail if you're using the accounts feature to keep track of separate balances (which is why it will probably never be a mainline feature). |
|
|
|
Meeting summary posted to the bitcoin-development mailing list ( link) IRC logs here. |
|
|
|
|
This doesn't affect Bitcoin at all, because the ECDSA algorithm that Bitcoin uses does not use pairs of prime numbers to do it's thing.
|
|
|
|
|
Show Posts
