|
Blockchain escrow is very recent, and I haven't used it yet. The other ones are more tested. A deposit is only necessary in a 2-way escrow if you think the buyer can dissapear and leave funds in limbo. If buyer dissapears and you use BTCrow or Bitmit, admins can confirm buyer's inactivity and release funds to you.
|
|
|
|
Escrow is simple, cheap, easy. There's no reason not to use it. Some escrows offer a deposit for both seller and buyer, so there's motivation for both parties to release funds. http://btcrow.com/http://thrucoin.com/http://bitmit.net/https://blockchain.info/wallet/escrowThe last one uses bitcoin's own multisignature system instead of relying on a third party, so it will be supported in the near future on bitcoin clients. I've been scammed with another iProduct. With bitcoin is too easy. Sellers that refuse to use escrow = SCAM. I've done several $200+ escrows, all of them completed successfully without intervention of a third party. |
|
|
|
|
It seems some personal data can't be changed, so I'm lowering the price to 5 btc. You'll have full access to the game anyway. I'm changing OP to reflect it.
|
|
|
|
I would suggest we add them as options, instead of full commands. Done. I'm changing my previous post to reflect the changes. |
|
|
|
I've modified electrum and made a pull request: Added two command line options for payto/mktx. From the help:
-s FROM_ADDR, --fromaddr=FROM_ADDR
set source address for payto/mktx. if it isn't in the
wallet, it will ask for the private key unless
supplied in the format public_key:private_key. It's
not saved in the wallet.
-c CHANGE_ADDR, --changeaddr=CHANGE_ADDR
set the change address for payto/mktx. default is a
spare address, or the source address if it's not in
the wallet If you want to try it, type this in your git sources: git pull git://gitorious.org/~dithi/electrum/electrum-dithi.git Or clone my source tree directly: git clone git://gitorious.org/~dithi/electrum/electrum-dithi.git Example of use: ./electrum -f 0.0001 -s 1NDzf48J8e1HRRnzY9uy61kj8xCg3xu2wo:5JQzVBjwkFMxECaKw3GBU2DhtPuWnbo8QsjWvdcESDisBdxx4mX payto 1AUjykoX6ZFzgKfBfetfKVC36fxCLMNFp 1.5 Usually you should omit the private key, so it is asked to you as a password and it's not saved into console history: ./electrum -f 0.0001 -s 1NDzf48J8e1HRRnzY9uy61kj8xCg3xu2wo payto 1AUjykoX6ZFzgKfBfetfKVC36fxCLMNFp 1.5
Private key:
-f 0.0001 is the fee (by default it's 0.005 and it doesn't use the value saved in the settings), you can type 0 but it takes longer to confirm. |
|
|
|
|
A good BDFL would have tested it enough before. They have much more patience and prefer long term maintainability over one-time patches, no matter how good they seem to be. Neither Gavin nor Luke-Jr have this reputation right now, I'm afraid... Anyway it's a good sign Bitcoin can't be changed too easily. I personally will be confident on any solution that also works in alternate bitcoin implementations (remember OP_EVAL raised alarms in a different implementation).
|
|
|
|
He is 'pretty confident' that he has found them all and I hope he is right.
Yeah, it's called "unit tests" and both BIP 16 and 17 have them. At this time BIP 16 passes more tests but I think BIP 17 is a good solution too. The whole thing has attracted too much public view just because one developer doesn't agree. I wonder what would Satoshi have done. In other projects I love such as Python and Blender, there's a "benevolent dictator for life" (BDFL) that has the last word. People trust them because they led their projects sanely for years. I'm really amazed with both Python and Blender. Guido van Rossum and Tom Roosendaal are my idols. Hm... both are dutch. Is there a dutch coder among bitcoin devs? |
|
|
|
This is such FUD from the Bitcoin developers. "Tested for months now", oh really? What about public support for it, maybe that has gone on for "months now"? I hope the devs push that as late as possible, after the public has had a chance to vocalize about the damage this will do to the decentralization and union of Bitcoin.
How exactly could it damage the decentralization? I think it's slightly improving it, as there are more and more supporters of P2Pool... |
|
|
|
What products or services do you suggest that can help bitcoin adoption?
Just about anything. There are a lot of niches to be filled. I will build an online game with a bitcoin based economy. |
|
|
|
lol, but to answer op, there were more sellers than buyers..
but WHY there were more sellers Because there are too many people "investing" in bitcoin just because, instead of offering products and services in exchange of bitcoins (which is what will really help bitcoin adoption). |
|
|
|
I agree that would increese the danger of loosing coins by loosing the keys stored on the 2nd device. One would need to run two programs and some ppl would end up storing both on the same device (if it would be possible to do) negating the security.
I bet most people will use 2-of-3 signatures: One in your PC, one in your phone and a paper backup, kept in a safe or something. If one of the devices get lost or broken, you use the other and the backup to move the funds to a new multisig address. Or you can use 2-of-4 and have two paper backups, one of them to be stored in a new device if one is lost (or using both backups if both devices are broken/lost, which is about the same of having only 2 signatures and a backup of both...). |
|
|
|
Hash the data + nonce
Check the answer, if it meets the difficulty critera then done
Otherwise increment the nonce and go to step 1
It's probable you won't find a block after trying all posible nonce values. When this happens, you modify something in the transactions (so the hash differs) and start again. That "something" it's usually called "ExtraNonce", a random number placed in the coinbase. |
|
|
|
You hash exactly the 80 bytes of the header, but it includes: - The hash of the previous block.
- The hash of all transactions in the block (or more specifically, the the root hash of a merkle tree of the transactions).
It makes no sense to save it: the previous block is always different and the more you wait, the longer the chain will be. |
|
|
|
|
Once we have multi-sig and GUI support for it*, we can finally market bitcoin as truly secure, and it will have a possitive impact on the price.
* The gui guides you to a multi-sig setup by default (pc+phone+paper backup).
|
|
|
|
Sorry, I can't resist to post this...  Pick a BIP and let's roll.
Agree! |
|
|
|
As he says, we will have "supernodes" BUT we won't need to trust them individually as we need to trust banks. Those "supernodes" will be the miners, and probably most of the information could be prunned from the merkle tree. If something like this gets implemented in the future, we just need to trust in that more than 50% of mining power is non-malicious in order to have a thin client that doesn't rely in any particular third party. Another thing I didn't mention here: If we reach 1/6 of the number of transactions of visa, fees will be higher than block reward (assuming a value similar to our current 0.0005 fee and 50 btc reward) |
|
|
|
|
This scares me, even if it's not my money, etc. Noobs should always know that transactions are irreversible and if you lose the wallet.dat, those coins are gone forever. If you did that, there's some chance of recovering the wallet.dat if you avoid doing anything else in that computer: shut it down now and ask here for some help from another computer.
|
|
|
|
It is pretty darn close to what I think would be the ideal solution. It even has a byte at the beginning of the redemption script hash that specifies what hash type to use (OP_HASH160) !
Except of course that you can't change the hash type - not even to the other hash type that Bitcoin scripts already support, plain SHA-256 - without getting everyone to upgrade and going through the whole process again. As soon as you change the opcode for the hash type the transaction stops being a P2SH transaction and there's no way to make it one anymore. It wouldn't face the same issues. If there's need for change, it would be just adding a hash function in the validation code. It would be either considered a security problem (so everyone would update as soon as posible) or a non important thing (so everyone updates at its own pace and then people start using it when there's enough support). |
|
|
|
Once transactions are validated and buried "deep enough" in the blockchain you can forget their inputs, because the inputs are only needed for validation.
... although SOMEBODY on the network should remember them, in case I-don't-trust-anybody nodes want to validate the entire blockchain.
Actually, I'm not sure this makes sense without major protocol changes. Currently, if you throw away the transaction inputs you can't prove to other nodes that the transaction was actually buried in the blockchain at the place you claim it was - transactions are hashed as a single piece of data and there's no way of verifying the hash without the entire transaction. So it's not really safe to bootstrap new mining nodes without a complete transaction history including inputs, even if they don't validate the entire chain. I asked that question regarding transactions that you know for sure if they have been spent or not. It was before I wrote this proposal to make sure I didn't misunderstand the protocol. Also, you can partially hash a transaction (in blocks of 64 bytes) until less than 64 bytes of the input section remains, so it would always ocuppy 63+32 bytes at most; but there's no need to complicate things. In my proposal you could just hash the outputs. |
|
|
|
|
Absolutely anything related with videogame development.
|
|
|
|
|
Show Posts
