on the subject of QR codes, you could just print a separate code above each item in the vending machine, then all a customer has to do is scan the code and push 'confirm' and the machine will vend whenever it receives a payment on the particular account.
Of course this means if you ever change prices you need to re-print codes with the correct payment value on it, but it does mean that no codes need to be entered into the machine at all.
I love that idea! Point your camera at the product, confirm payment, and you're done. RE: changing prices: I wonder if you could make little QR-code-capable LCD or e-ink displays cheap enough to put 20 of them in a vending machine. It'd also be a great opportunity for practical jokes, like making the machine vend... oh, I dunno, Nerds TM along with their popcorn. |
|
|
|
Out of curiosity why isn't there a mechanism to write two wallet.dats atomically (both have to succeed), one to the [%APPDATA%|$user]\bitcoin directory, and another to a usb key or alternate drive?
or even to -dumpwallet after each transaction on the client?
Because we don't have infinite programming resources, and we've been busy working on low-level stuff that will lead to solutions that will fix the "my hard drive crashed" and also the "my computer got infected by malware" and "my house burned down along with my computer and all of my USB thumbdrives" disaster scenarios. |
|
|
|
|
I hate to inject gloom and doom into a fun topic like vanity bitcoin addresses... but y'all should be aware that one of my longer-term goals for the Bitcoin system is to make bitcoin addresses disappear. I hope Bitcoin software 10 years from now tells users "You're about to pay 11 micro-Bitcoins to Amazon.com" and not "2mRwtf8blahblahblah". And I'm not alone, I know Mike Hearn feels strongly about making bitcoin addresses go away for ordinary users.
If you do spent lots of time creating The World's Best system for mining vanity bitcoin addresses, please don't be upset or surprised if you find it is obsolete when "Bitcoin 2017 Turbo++ Enhanced Edition" is released.
|
|
|
|
Just thinking out loud... ... but vanity addresses using 1-of-2 multisignature transactions and BIP 13's new bitcoin address format could be orders of magnitude easier to generate. You'd start with a normal keypair. And simply compute the hash of the public key and another, arbitrary, "I don't have the private key but I don't care" public key (in an "OP_1 <public_key> <don't care public key> OP_2 OP_CHECKMULTISIG" transaction type). You'd always spend the funds sent to the vanity address using pk1. No expensive ECDSA addition or multiplication required, just lots of SHA256/RIPEMD160 hashing and base58 encoding and string comparing. ----------- Widespread use of the new pay-to-script address format will have to wait until "everybody" upgrades to support it, though. And it does make transactions larger (2 public keys instead of 1) than the find-the-right-private-key solution. |
|
|
|
Do you guys think it would be a good idea for the client to check if the wallet has been switched out, and if so, to do an automatic rescan?
Newer versions do this already. |
|
|
|
I am sad that all gavin's work have been wasted!  Don't be sad-- it hasn't been wasted at all. Most of the work was making multisignature transactions work properly, the OP_EVAL part was a small amount of code (which becomes an even smaller amount of code under the new PayToScriptHash scheme, which is one of the reasons I like it). And re: new cycle of coding/testing/etc taking 3 more months: I'm going to propose slipping the schedule by two weeks, which means a "network is fully validating the new transaction types" of Feb 15 instead of Feb 1. |
|
|
|
give me an example of a mistake at this stage of my scenario that would implicate the owner of D.
Ok, here are three: Authorities gather enough circumstantial evidence to get a warrant. They raid the guy's house/office, and find a wallet on an unencrypted hard disk with private keys corresponding to "B". That should be enough evidence to convict. Or the guy thinks he's being clever by breaking up his 10,000 BTC into 50 BTC chunks and slowly, over time, transfers them to new wallets C, then D. Then deletes B and C. But he doesn't realize that the graph of transactions he is creating would be IMPOSSIBLE to happen by chance if wallets B and C belonged to innocent bystanders (what are the chances that, say, 10,000 stolen bitcoins were broken up into a bunch of pieces and then just happened to end up later in the SAME wallet?) Or somebody with lots of connections to the bitcoin network is figuring out (with pretty good precision) what IP address each transaction is coming from. The guy doesn't use a proxy to hide his IP address, and the transactions from A->B->C->D all appear to come from IP addresses allow assigned by the same Internet Service Provider in the guy's town. The authorities subpoena the ISP and find out the guy was assigned those IP addresses when the transactions hit the network. ---- All of the above is why I say it is hard to be anonymous when using Bitcoin, and I'd urge you not to do anything with bitcoins that would prompt The Authorities to bother getting subpoenas/warrants to try to figure out who you are. |
|
|
|
Anyone interesting in creating and testing more unit tests together?
Good Idea. How are you creating the files? What language are you writing in? Anybody want to volunteer to write a Satoshi-bitcoin unit tester in C++ that parses ThePiachu's format? Or do you already have code that runs them? Committing a gazillion Script unit test cases to src/test/scriptTests/ sounds like a very good idea to me. |
|
|
|
|
Wallet.dat files don't get corrupted very often; blkindex.dat or addr.dat corruption is much more common (which makes sense, they are much larger and changes all the time as new blocks are added/indexed).
A lot of reported "database corruption" has been Berkeley DB log file incompatibility (the .dat files are compatible between 4.* releases and across operating systems; I know the log files are NOT compatible from 4.7 to 4.8, I think they're cross-OS compatible too but could be wrong about that).
The Satoshi bitcoin code could certainly do a better job of helping users recover from any/all of the above, although I personally think that development time would be better spent on the "what if my computer catches fire" scenario-- can we make it really easy for users to securely backup and restore their wallets off-site?
|
|
|
|
|
The client doesn't support multisignature transactions yet.
|
|
|
|
Can you do a "1-of-1 or 2-of-2" transaction, where either the overseer spends the coins, or both the overseer & the holder spends the coins?
You can do 2-of-3 (overseer holds 2, so can always spend, you hold 1) instead to accomplish the same thing. I suppose having the overseer put transactions in the block-chain that everybody can see might make you and the people you're paying trust them more... |
|
|
|
|
TrundleNet (no reason)
Transactinator (T13 for short)
Eleventy (because eleven is my favorite number)
|
|
|
|
|
Disclaimer: I'm a Tor newbie and networking stuff isn't my strong suit, you probably know more about it than I do.
But: I fixed a Tor-related bug for version 0.6 a few days ago. In particular, I moved all of the "turn this on or turn this off if running over Tor" to one spot (in the init.cpp file) and reworked the code so that you can override all of those decisions via command-line or bitcoin.conf switches (e.g. specify -nolisten=0 to set nolisten to false so you DO listen even if running a port 9050 proxy).
|
|
|
|
Is it possible to construct a custom transaction in which either your key, or the key of an "overseer" can spend the coins?
Yes. That would be a "1 of 2 signatures required" multisignature transaction. And add a feature such that all subsequent transactions you make also have to include the overseer's override feature?
That you can't do. If the coins were stolen, the thief can just sign them away. I suppose you could do a "2 of 2 signatures required" and then have the overseer only approve transactions that were ALSO 2-of-2 required (where 1 was the overseer's signature). A thief could take your coins away, but wouldn't be able to spend them without the overseer's OK. The overseer wouldn't be able to take them back, though. More complicated schemes are probably possible if you want to trust the overseer completely... but if you and the person you are paying trust the overseer completely then why bother using bitcoin transactions at all? Just hold accounts at the overseer and they can transfer balances or reverse transactions as they like.... |
|
|
|
There are rumors that the Bitcoin network will split in two, one side, people using 0.5.1, 0.4.0.... On the other side, people using 0.6.0... I've been working hard to make sure there will be no blockchain split, and I've convinced myself I've thought through all the "old/new client sending transactions to an old/new miner" cases. The only case where an old miner could be split off the network is if they are mining non-standard transactions (which means they've modified their mining code) and do not upgrade. If you are in that situation, then you should either stop adding transactions containing OP_NOP1 into your miner's memory pool or upgrade to interpret OP_NOP1 as OP_EVAL. But I've said it before and I'll say it again: don't trust me. I make mistakes. Two serious bugs in my OP_EVAL/multisignature code have been found (and fixed) in the last week. Version 0.6 will have at least a month of release candidate testing. I still firmly believe the benefits of the new 0.6 features far outweigh the risks. Please help minimize the risks; review code if you can, run release candidate on the testnet and try to break them, read the BIPS and try to think of ways bad people might use them to do bad things. Review the contingency plans and think about how they could be improved or if you could help when (when, not if) vulnerabilities are found. |
|
|
|
|
makomk reported a remote vulnerability that I pulled into the master bitcoin/bitcoin tree on December 20. If you are running git-HEAD code on the production network you should pull the latest code to get the bug fixed.
This affects only anybody who has pulled and compiled their own bitcoind/bitcoin-qt from the source tree in the last 5 days.
Gory details:
I made a mistake. I refactored the ConnectInputs() function into two pieces (FetchInputs() and ConnectInputs()), and should have duplicated a check in ConnectInputs for an out-of-range previous-transaction-output in the FetchInputs() method. The result was a new method I wrote to help prevent a possible OP_EVAL-related denial-of-service attack (AreInputsStandard()) could crash with an out-of-bounds memory access if given an invalid transaction.
The bug-fix puts a check in FetchInputs and an assertion in AreInputsStandard. This does not affect the back-ported "mining only" code I wrote that some miners and pools have started using.
The good news is this was found and reported before binaries with the vulnerability were released; the bad news is this was not found before the code was pulled and could have made it into the next release if makomk had not been testing some unrelated code.
Before releasing 0.6, I would like to have an "intelligent, bitcoin-specific fuzzing tool" that automatically finds this type of bug that we can run before every release. If anybody already has one, please speak up!
|
|
|
|
The most important metric would be when the block was received. If I receive a block that tries to replace a block 6 or 10 or 100 blocks ago on the chain I already know about, and I have no reason to believe I've been segregated from the network at large, I'm not going to vouch for it.
Yes. The times the blocks are announced also matters; if my node suddenly sees a longer 10-block chain it has never seen before, then either it is a 51% attack or the network was split and just came back together. If the network was split 10 blocks ago then I should see that those 10 blocks took twice as long to create as expected. Rating blocks is a neat idea; I can think of several potential criteria, there are probably more we could come up with: - Did I first see the block announcement long after the block's timestamp?
- Does it look like it is part of a network split? (two chains that are both producing blocks more slowly than usual)
- Are they part of a sub-chain with a 'normal' distribution of blocks from the well-known mining pools? (an attacker's chain won't have blocks from ANY of the mining pools)
- Does it contain any double-spends that conflict with alternate chains I know about?
- Do the transactions in it look 'normal'? (reasonable number of transactions, reasonable amounts)
Somebody should simulate some 51% attacks and network splits and try out various detection algorithms. And maybe see if it would be practical to have a checkpoint lock-in rule of something like "auto-checkpoint any AAA-rated block once it is 4-deep in the best chain". I don't think that should be built-in to bitcoind, but a little side program that monitored the block chain and the pools and told bitcoind to add a checkpoint once an hour or so would be pretty spiffy... |
|
|
|
|
Show Posts
