Maybe, but this article doesn't seem to have it. The quote was about two-three lines long.
Man, tons of those. Maybe this? The death blow to the nation-state will be digital cash, which has just become available. E-cash or even e-metal, using encrypted verifiable signals will allow individuals to make their transactions in secret on the Internet, and will destroy the ability of governments to exact wealth through the hidden tax of monetary inflation. Using financial institutions domiciled in tax havens, and using anonymous remailers, cybernauts will be able to largely avoid taxes and inflation, and thus amass wealth at a vastly accelerated rate.
- http://www.isil.org/resources/libertydocs/sovereign-individual-book.html |
|
|
|
|
Will bitcoin coexist with other "proof of work", decentralized cryptocurrencies? I think there is only one winner there. Any competing proof of work cryptocurrency that doesn't rely on Bitcoin (e.g., a merged mining side chain) is vulnerable to attack by those trying to protect Bitcoin's value.
I've been told by people much smarter than me that I'm being naive in that belief though. We'll see.
As far as coexisting with other centralized cryptocurrencies then I believe it not only will, it already does. A crypto currency that is non-reversible makes a very good match for trading to and from Bitcoin. Mint Chip might be one. Open Transactions will hold and trasnsact new ones that anyone can create. Heck, even GLBSE share issues might be considered a type of digital money that interacts well with Bitcoin.
|
|
|
|
I live in Ontario, Canada, the electricty rates during peak times are 8.8 cents per kWh and 7.5 cents per kWh.
That's about half the average for U.S. residential rate. You would probably do well mining, though there is an upfront investment and it willl be some time before future mining revenues cause there to be profit that exceeds that investment, likely well more than a year out for that to happen. |
|
|
|
I remember reading some interesting cryptography and Bitcoin-related quote recently, but I can't for the life of me remember where I found it or how it was phrased exactly. Can someone help? It was a quote about the fact that political powers want to use the force they have to control money production, but that cryptography algorithms are immune to any power one can use against it. Does that ring a bell to anyone?
Possibly from this by Matthew Green? - http://blog.cryptographyengineering.com/2012/05/future-of-electronic-currency.html |
|
|
|
Heh, We'll fetch a real random number between 1 and 16384 from random.org.- You completely miss the whole point of SatoshiDICE and why it (and BitLotto for instance) is different from other online wagering services don't you? |
|
|
|
Is the site down for anyone else? I'm in Cambodia, and gambling is perfectly legal here, so I can't see why it would be blocked. Oddly though, Strike Sapphire loads the same blocked region message I would get when I was in the US, so that has me thinking this could be related if the site is up for everyone else.
Edit: Just used a proxy and it loads. Weird. They do censor here, but it is usually political stuff.
There are some cloud based filtering (e.g., opendns, or MyWoT) system which take user submissions without validation. Could be your system has that or somewhere along that line the site got flagged. Actually I see MyWoT shows an +80 for SatoshiDICE on trustworthiness, ..., which is fantastic, but has a low confidence likely as so few ratings have been given. Now if SatoshiDICE were to already be making it into the national firewall / censor systems that would be interesting. |
|
|
|
$100 & $200 denominations available instantly.
Other denominations are available for next day delivery. What maximum? Are there levels, or can I buy a card with $567.89 on it? Are these usable at an ATM? Are these usable internationally? Can they be reloaded? |
|
|
|
Can someone explain how they'd fork the blockchain?
Bitcoin is a protocol. The Bitcoin.org client is code that implements the Bitcoin protocol. This taint blacklist idea of yours could be implemented in a client without touching the Bitcoin protocol or requiring a hard-fork to the blockchain. So my reference earlier to a fork was describing alterations to the Bitcoin.org client and not to a fork of the blockchain. As you also mentioned, you could even implement a taint blacklist that does not require changes to the Bitcoin.org client (e.g., this could easily be done in Armory, for instance, or some other external service.) So, it's technically very possible for you to do this. Go do it. What are you waiting for? Go nuts! The reason you haven't is because you know that unless others are using that taint blacklist as well, you doing so unilaterally has no effect. If you'ld like to boycott tainted coins, you don't need anyone's permission. You are free to do so. Isn't Bitcoin and open source fantastic, where you have the liberty to take the software and to basically be allowed to do pretty much whatever you want to with it? Now if instead you want to change the software that I use, that's when I start to have a problem with you. Your freedom ends where my nose begins. |
|
|
|
There were some very good points made in this thread and just so that they aren't overlooked I'm putting in a recap / summary: Keep a copy of your current wallet before doing this, of course.
Yes, step 1 of any offers given to help someone in a scenario like this should include: Before you try reverting to an old wallet, or performing pywallet surgery on your wallet, make sure that you make a backup (or two) of your current wallet.In this instance, Jeremy made over 100 transactions. Had he reverted to an old wallet, and wasn't using a large keypool already, there is the possibility that he would have given out Bitcoin address and received payments to them where these addresses didn't exist yet when the most recent backup was made. Hopefully everyone actively using Bitcoin at these levels is well aware of the keypool and has adjusted the keypools size to be large enough so that the backup and recovery strategy will make it so there is not ever result in lost bitcoins because of not having backups that include new keys. Here's notme's mention of that: I think the default keypool is only 100. If you're doing this many transactions you should set the keypool size to 1500 or some other high number so your backups are at least valid for a few days. The Bitcoin.org client isn't clogged up to accommodate every use case out there, so merchants should know that the -keypool=<n> configuration setting and a good backup strategy require proper attention to prevent the situation where there are lost bitcoins. If your backup strategy is to take a nightly snapshot (shut down the client & copy the wallet.dat) and retain that backup copy for each night over the past 7 days, then you probably want a key pool of multiple days worth of transactions (or, more specifically large enough for multiple days worth of addresses that are consumed from the keypool). As notme suggests, 15X daily usage is not rediculous (they're really cheap so why not!). To the devs: isn't this a bug in the Satoshi client? Shouldn't the client try to rebroadcast unconfirmed transactions once in a while? If it does rebroadcast, just not fast enough for Jeremy's needs, then isn't this an enhancement issue that should be logged anyway?
The client will rebroadcast within in a half hour. The normal use case is for this to not occur on startup as that lessens the transaction anonymity. The ability to force a rebroadcast was discussed but the conclusion was that the range of zero to 30 minutes was sufficient so the ticket was closed: - https://github.com/bitcoin/bitcoin/pull/421So after the cosmetic problem where there are 0/unconfirmed transactions is resolved for Jeremy it would be useful to try to understand what might have caused this to occur in the first palce. There is an attack in which this exact situation could be the result (the vector76 attack or "one confirmation attack") but that probably isn't what happened here. Further information on this attack here: - https://github.com/bitcoin/bitcoin/issues/1428Ending up in this situation where you have these 0/unconfirmed spend transactions that will never confirm isn't something that is easy to do unless either you are doing something wrong (e.g., either purposely trying to double spend, or accidentally double spent by using the same wallet on multiple nodes and unwittingly created a double spend in the process) or you happened to not only be the target of a double spend but you happened to also use funds from that double spend for a spend transaction yourself. Any guess as to what might have happened here? |
|
|
|
|
Ok, pasted the ad code again and it is working now. Not sure what I was doing wrong before.
|
|
|
|
It can work *in a more mainstream setting* - because it's viral in nature, and if your local supermarket subscribes to a particular taint-list, it's in your interests to have wallet software which *understands* the taints that this supermarket subscribes to and the (initially small) penalties(taxes) it is enforced to enact. Enforced? By whom? It matters not. Because it is so easy to mix coins, all you need are enough people willing to throw their 100% untainted coins into the mix and your approach fails miserably. "There's a time when the operation of the machine becomes so odious—makes you so sick at heart—that you can't take part. You can't even passively take part. And you've got to put your bodies upon the gears and upon the wheels, upon the levers, upon all the apparatus, and you've got to make it stop. And you've got to indicate to the people who run it, to the people who own it, that unless you're free, the machine will be prevented from working at all." - Mario Savio Hows that? Mostly irrelevant. Tainting will work in a world where the core bitcoin.org software *never* implements any taint-aware code. Ok, good. So there will be no code in the client that will try to load your no-fly list. That's fine then. It'll be locally applied, and thus people will be locally incentivized to have taint-aware wallets - even if they hate the whole idea. Have you been shopping on Silk Road? |
|
|
|
Most of the complaints here seem to be of the sort: "I don't like it!!!" No, the complaints are saying it won't work. And unless you come up with a new reason why it might, we just keep going around in circles. I'm also not convinced that just naysaying it will stop it from popping up. Ok, how's this. If anything in the open source Bitcoin.org project for taint were to be added I would help towards getting going a fork of that project where there would be no such concept or recognizance of this concept referred to as taint. I would do what I can to help beat this idea into the ground to which it belongs. |
|
|
|
|
When does this happen? During launch?
What version of the client?
Step 1. ) make a backup of your wallet.dat
You might next try re-downloading the blockchain.
Basically leave wallet.dat and remove everything else in the Bitcoin folder. (or use Blk*.dat files from a blockchain nightly).
Does the problem persist after doing this?
|
|
|
|
I had posted this in another thread, but it applies here as well. But we don't solve it by simply using something else (e.g., Dwolla). We fight PayPal by doing what we can to make Bitcoin's ecosystem work for us. If you have a prepaid mobile phone, then you pay for your wireless phone refills using one of the three services that accept bitcoins for that: - Tangible Cryptography: http://bitcointalk.org/index.php?topic=82924.0 -- Catalog: http://www.bitmit.net/en/user/TangibleCrypto - BTCBuy.info - http://btcbuy.info/CallingCards.cshtml - Bitcoin Wireless - http://signup.bitcoinwireless.com (Coming soon) Or next time you fly in the U.S., you try to take Southwest so that you can pay for the ticket through Spend Bitcoins: - https://www.spendbitcoins.com/convert/southwest-airlines/Or you need some tools, or houseware's ... - http://www.bitcoindeals.comAnd you carry around a few physical bitcoins, so that you can show people bitcoin in a way that might help them associate this abstract concept of digital money to a physical item familiar to them. - http://www.Casascius.comAnd you remind every merchant that uses PayPal or other payment system that there's this Bitcoin thing that has advantages they might like, ... like non-reversible charges, low cost transaction fees and fast settlement allowing the funds to be spent in about an hour or less. That's how the road toward fixing Bitcoin's Bug #1 is traveled. |
|
|
|
I see that Blockchain.info uses both Mt. Gox yubikey and Yubico's yubikey. There's a potential security issue using the default authentication method which uses crc16 and thus a valid looking authorization token can be obtained without having the AES key. Is Blockchain.info using this crc16 method or otherwise vulnerable to this? - http://bitcointalk.org/index.php?topic=85648.msg943612#msg943612 |
|
|
|
|
I think SatoshiDICE needs a big disclaimer so every player is aware that the service is "beta" level at this young point in its life (launched just 6 weeks ago) -- and that payouts may take 48 hours -- or something like that.
|
|
|
|
Assuming there was some form of civil liability and that a miner/operator wouldn't just disappear into the night, the vig is not very high. You can use my exact same example above and issue just 90% of current hashing capacity and keep 10% to pay for operational costs. Yes, there is the miner/operator's time, but other than that, I don't see the high risks you're talking about. Isn't a bond a debt? If the issuer is an individual (sole proprietor), that that person is responsible for repayment (regardless if the funds from the bond were raised for this commercial endeavor or not). Now if the operator is in a different jurisdiction or operates anonymously where you cannot prove that's where the proceeds of your bond purchase went then good luck with getting any relief. And then those perpetual bonds ... I suppose the only claim there is on the revenue lost from the interest payments missed? |
|
|
|
|
One of the reasons the #bitcoin-otc Web of Trust (WoT) is relied on by so many traders is that thanks to GPG you can be sure that your counterparty truly is the party with the trust history, and not an imposter.
BitcoinTalk forum does not use any security greater than username and password, and we know how many people don't use strong passwords.
So there is the risk of you verifying a seller, and then a scammer uses the credentials of that seller's account to scam.
Would you consider including in your verification an optional step that lets the seller provide a #bitcoin-otc WoT username (and verify that with you)?
|
|
|
|
|
Show Posts
