|
I like it. But it needs additional elements to be an effective symbol, I think -- perhaps it should be put on a coin image.
|
|
|
|
|
I don't like the "latin" sound of Esperanto (as well as Spanish, French, etc.). Lojban sounds better.
Bitcoin probably will always be niche, but that doesn't really matter. As long as it exists, people can use it if they want to. Bitcoin is useful even with just 1,000 users, unlike Esperanto.
|
|
|
|
|
You could create a new address, send some coins to that address, and then export just that address.
Since you trust yourself not to double-spend, you can create a transaction and save it to disk without broadcasting it. However, spending any of the specific coins used by this transaction would make the transaction invalid, so you'd be essentially freezing those funds, which is unlike your example of writing a check.
|
|
|
|
|
The command is:
./bitcoin.exe -addnode=192.168.1.48
Including switches without "-" makes Bitcoin think that you want to run it in RPC client mode. It was thinking that you wanted to run a Bitcoin RPC client with the -addnode switch, sending the RPC command "192.168.1.48".
|
|
|
|
I thought of a simple way to implement the timestamp concept I mentioned above. Run sha1sum on the file you want to timestamp. Convert the result to a Bitcoin address, such as via http://blockexplorer.com/q/hashtoaddress . Then send a small payment to that address. The money will be lost forever, as there is no way to spend it further, but the timestamp Bitcoin address will remain in the block chain as a record of the file's existence. I understand that this is arguably not a good use of the Bitcoin distributed database, but nothing stops people from doing this so we should be aware that it may be done. Interesting idea. You don't need to convert it to an address -- Bitcoin deals with plain hashes internally, so you can just use the hash output. (Of course, using an address makes it possible to use existing versions of Bitcoin as a generic timestamp server.) It might be better for the network to use OP_DROP. It is provable that "<constant> OP_DROP" is irrelevant information, so later versions of Bitcoin might allow people to delete that part of transactions to save space. |
|
|
|
Interesting. How does this work?
What stops a generator from including the transaction before its time? The signed transaction contains the date in it, in a way that it can't be separated?
And how does the cancel message makes sure no generator will include the transaction in a block anyway?
The lock time is signed. Everyone will reject the block if it includes a transaction before its lock time (this rule is already in effect). Revoking is a bit more risky. If 1% of generation power doesn't support revoking unlocking transactions, then there's a 1% chance that the revoke will fail. In this case a failed revocation is just an "accidental withdrawal", though. |
|
|
|
Wow, so we don't need a bounty at all?
Well, you can't use the feature until most of the network re-enables it. And even if it is enabled, the UI parts of it probably won't be available immediately. |
|
|
|
|
You could do it if the transaction locking system was re-enabled. It would work like this:
- MtGox sends everyone's money back to them, but with a lock time 30 days in the future.
- These transactions can't be included in the block chain until the specified lock time has passed. Once the lock time has passed, they will be automatically included in the block chain and irrevocable. To the recipients, they will appear in the client as "Open until 2011-01-05" or whatever, and will not be spendable or reflected in their balance.
- MtGox can "hit the dead-man switch" by revoking these transactions. Only the person who owns MtGox's Bitcoin keys is capable of revoking the transactions.
This is a feature that actually exists in the client right now, but it was "temporarily disabled".
|
|
|
|
|
No. Ultra-lightweight clients that don't even download the block chain except headers ("standard" lightweight clients download the chain and then discard most of it) need to receive full transactions from the sender. I think this will be the standard way of doing transactions in the future. IP transactions make a good base for this: we just need authentication. Authentication is even designed: people will provide static Bitcoin-address-like public keys along with IP addresses.
|
|
|
|
Ah, thanks. Is this just a UI issue with display of transactions, or do the clients not recognize the transfer of value at all? If that address 179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uB goes on to spend its value (supposing its client was patched to allow it), would the transaction be accepted as valid?
The client doesn't know how to solve the transaction's scriptPubKey. It can evaluate a complete scriptSig+scriptPubKey, but it can't produce a matching scriptSig for a strange scriptPubKey because it doesn't recognize the scriptPubKey's template. A patched client can solve the transaction. An unpatched client won't even recognize a non-standard transaction as its own when scanning the block chain. If a client is sending strange transactions, then the receiving client also needs to be modified to receive them. If that's the case, then there's no problem. |
|
|
|
Thanks for the comments. To clarify, do you mean that transactions with OP_PUSHDATA and OP_DROP, etc would be rejected by current clients?
They would not be rejected by the network, but transactions that differ at all from the two standard transactions can't be received by standard clients. So if I take a standard transaction to 179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uB: OP_DUP OP_HASH160 43716564ed4d679067da12bee139fd294c1f1b84 OP_EQUALVERIFY OP_CHECKSIG And I add some extra data to it: "BitDNS v0001 asdf" OP_DROP OP_DUP OP_HASH160 43716564ed4d679067da12bee139fd294c1f1b84 OP_EQUALVERIFY OP_CHECKSIG 179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uB will not even see my transaction in their client because they don't know how to read that modified transaction. It will still be in the block chain, though. |
|
|
|
|
That might be suitable in some cases. With Bitcoin, lightweight clients can download just the 80-byte block headers for each block and still securely verify transactions, but this is only possible because the network verifies transactions before including them in blocks. The network can't verify overlay transactions, so overlay clients will have to download the entire block chain. This will become a problem when the block chain is 1,000,000 blocks long and you have to download 1+ TB of data to use BitDNS.
A more minor problem is that the bitcoins associated with these transactions become unusable. If the transaction is spent, the network is allowed to forget about it, so you must keep the transaction unspent for as long as you need the data within it to stay alive. Also, Bitcoin clients will not recognize non-standard transactions. If you send one of these transactions to someone not using a modified client, they will just ignore it.
It's unnecessary to use OP_NOP1 as a flag. Just say:
"BitDNSv0001 <transaction data>" OP_DROP ...
|
|
|
|
|
Bitcoin will randomly discard any sub-0.01 balance you have, so it would probably be better to round down to the nearest 0.01. The server can keep a running sub-cent balance for addresses, and pay them when they reach a cent. If an address doesn't contribute for a while, their balance can be returned to the pool. This also solves the problem of people who don't contribute much.
|
|
|
|
I'm talking two large chains where perhaps the "larger" chain has blocks with inferior hashes with significantly lower difficulty.
"Length" is calculated as combined total difficulty. You can see this in debug.log: SetBestChain: new best=000000000008a779f5a8 height=92528 work=136473134420632176 |
|
|
|
What are pool contributors thoughts? Change to this method?
I would prefer "contributed". It seems more fair. |
|
|
|
How do the generate transaction coins actually work? I mean generally, nothing about pooled mining. Are the coins actually no good yet? Or is the client set to stop them from being used for 120, but that could be circumvented?
What happens if you have pooled generate coins go to mtgox or mybitcoin? When would they be available? Would they be completely invisible for 120 blocks? Or immediately available?
Generations can't be spent for 100 blocks. Transactions that try to spend them before that will be rejected by the network. The client has an additional 20-block safety margin. This limit exists because generation transactions within a smaller chain become invalid when merged into a larger chain. If this limit didn't exist and the network was split for a few hours, hundreds of people could find their transactions invalidated if their transactions use any coins from recent generations. It's impossible to view non-mature generations using stock bitcoind. They will be invisible to MtGox/MyBitcoin until they have matured. |
|
|
|
I'm curious about the .00000044 payment also, was it just an unlucky miner who logged on just as the block was solved?
That's rounding error going to the server. Wow. It actually say generated?
Yeah! Puddinpop designed this wonderfully: the bitcoins are actually broken up in the block you are solving. Bitcoin sees it as if you generated the bitcoins yourself, and sub-0.01 fractions can be included without any problem. |
|
|
|
This is so awesome!  |
|
|
|
I don't know how to visit a Tor site (if that's that this link is).
You can add tor2web.com: http://44eeao3qvv2wz3vv.tor2web.com/This is not secure, but it allows you to view Tor hidden services without installing Tor. |
|
|
|
Thanks, I had a way to get there. More curious about the mechanics of what is going on. A domain name be blocked in one country and not another, right? Is it being blocked in the US, everywhere?
The Wikileaks DNS server is not responding. It is not being blocked in any one location. Some people may still see it resolve due to DNS caching. EveryDNS.net provided domain name system (DNS) services to the wikileaks.org domain name until 10PM EST, December 2, 2010, when such services were terminated. As with other users of the EveryDNS.net network, this service was provided for free. The termination of services was effected pursuant to, and in accordance with, the EveryDNS.net Acceptable Use Policy.
More specifically, the services were terminated for violation of the provision which states that "Member shall not interfere with another Member's use and enjoyment of the Service or another entity's use and enjoyment of similar services." The interference at issues arises from the fact that wikileaks.org has become the target of multiple distributed denial of service (DDOS) attacks. These attacks have, and future attacks would, threaten the stability of the EveryDNS.net infrastructure, which enables access to almost 500,000 other websites.
Thus, last night, at approximately 10PM EST, December 1, 2010 a 24 hour termination notification email was sent to the email address associated with the wikileaks.org account. In addition to this email, notices were sent to Wikileaks via Twitter and the chat function available through the wikileaks.org website. Any downtime of the wikileaks.org website has resulted from its failure to use another hosted DNS service provider. |
|
|
|
|
Show Posts
