Now, I could be wrong, and it may be that any coins stored this way must be fully spent when signed, instead of being able to be spent in parts (vault has to be emptied entirely, portion is sent to the recepient, remainder goes back into the vault maybe?)
Two-people-required-to-spend bitcoin addresses would be a great feature for blockchain.info. Coins would be sent to that address, then both address owners would have to agree to spend them (by signing transactions). The incoming coins do have to be fully spent, but it is easy to create transactions that send the change back into the "vault" (multisig address). |
|
|
|
|
Yeah, not Satoshi. Satoshi has red hair and a big handlebar moustache.
|
|
|
|
|
Is Decrits meant to be a decentralized solution?
How is the coin minting queue managed? E.g. you say "Once enough minters have joined the queue..." : what if there is disagreement about which miners are in the queue or if there are "enough"?
|
|
|
|
Release candidate 3 binaries are up; major differences from rc2 are: 1) Fix the IPv6 RPC problem (you will get a warning in debug.log, that is expected) 2) Updated translations ------ We could use more people "gitian building" releases; if you have a machine with at least 3 gig of memory and 20 gig of disk space, you can now help reproduce the builds using LXC running inside something like VirtualBox: https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/README#L57 |
|
|
|
BCDataStream.write takes binary data, so add a .decode('hex_codec') to the big long hex string: test.write("0100000001da8d10a3b749dbda1658298d84512836c1bfb2bcbe7b61dcdd3e508bcb7e1477000000006c493046022100e041a6e5df8c8b44231b4fee02b34e2f12d553ab54dc434c1bf95dffb68e5f8d022100c74e5318b4c209397be7e1ea4f4ef783d036f5fbe894918e8e31c72e49f75fc30121034ecf9a2859c419500001e05710bec6673db9a8ea5faaf07497c9c996e1d28f81ffffffff0280324c35800000001976a914fc8e972d3f4c41b44a3ee71051aaf52f107ceb0f88ac005cb2ec220000001976a914847641ad2efb44d949070bf6e7b1c367c70f194388ac00000000".decode('hex_codec'))
parse_Transaction(test)
{'lockTime': 0, 'version': 1, 'txIn': [{'sequence': 4294967295, 'prevout_hash': '\xda\x8d\x10\xa3\xb7I\xdb\xda\x16X)\x8d\x84Q(6\xc1\xbf\xb2\xbc\xbe{a\xdc\xdd>P\x8b\xcb~\x14w', 'scriptSig': 'I0F\x02!\x00\xe0A\xa6\xe5\xdf\x8c\x8bD#\x1bO\xee\x02\xb3N/\x12\xd5S\xabT\xdcCL\x1b\xf9]\xff\xb6\x8e_\x8d\x02!\x00\xc7NS\x18\xb4\xc2\t9{\xe7\xe1\xeaON\xf7\x83\xd06\xf5\xfb\xe8\x94\x91\x8e\x8e1\xc7.I\xf7_\xc3\x01!\x03N\xcf\x9a(Y\xc4\x19P\x00\x01\xe0W\x10\xbe\xc6g=\xb9\xa8\xea_\xaa\xf0t\x97\xc9\xc9\x96\xe1\xd2\x8f\x81', 'prevout_n': 0}], 'txOut': [{'value': 550650000000, 'scriptPubKey': 'v\xa9\x14\xfc\x8e\x97-?LA\xb4J>\xe7\x10Q\xaa\xf5/\x10|\xeb\x0f\x88\xac'}, {'value': 150000000000, 'scriptPubKey': 'v\xa9\x14\x84vA\xad.\xfbD\xd9I\x07\x0b\xf6\xe7\xb1\xc3g\xc7\x0f\x19C\x88\xac'}]}
|
|
|
|
Hoisted from the comments on pull request 1809:Only data that is strictly necessary for the world to validate a transaction has a place in the block chain. That's the whole point of it. Everything that is only significant to the sender and receiver (or miner) should be between the sender and receiver (or miner) and doesn't need to be stored forever by every other full node in the world. I think there are definitely use-cases for associating some immutable meta-data with a transaction. Example: a bitcoin client that gave a unique refund address for every outgoing transaction, and automatically groups refund transactions together with the original payment transactions. Somebody could create a service that associates data with transaction ids, but they need to do more work to make the data immutable... and it is not clear to me how you make that secure. I really want my refund address to be 'baked in' to the transaction that I sign, so if the transaction is accepted into the block chain I know there hasn't been some hacker somewhere who managed to rewrite the refund address so they get my coins. If I'm doing some type of smart contract with bitcoin transactions, I want the contract data baked in and covered by the transaction signature. And the person I'm transacting with would like to be sure I can't change the terms of the contract once the transaction is signed. It seems to me the simplest, most straightforward, and secure way to do that is with a limited-data OP_DROP transaction type. The data in the blockchain is (transaction+HASH(metadata)), and that is what is signed. The actual metadata can be stored outside the blockchain and looked up (and verified) by hash (hand-wave, hand-wave, I have no idea how that happens, if there is more than one place that stores transaction metadata, etc). Any scheme that tries to move the HASH(metadata) outside the transaction signature recorded in the blockchain will, at the very least, be more complicated. And, therefore, very likely to be less secure. Am I missing some other simple, secure, decentralized, non-blockchain scheme for attaching metadata to transactions? |
|
|
|
|
Consensus is the RPC-doesn't-work-if-you-disable-IpV6 bug is serious enough to hold up the 0.7.0 final release.
So the plan will be: get a fix for that bug and release/test a 0.7.0rc3.
|
|
|
|
I just submitted a pull request to fix this: https://github.com/bitcoin/bitcoin/pull/1818This pull request makes three functional changes: - Adds "redeemScript" to listunspent output, when listing a p2sh/multisig output
- Adds "redeemScript" to signrawtransaction's second argument (list of previous transaction outputs)
- Adds a new RPC command, "createmultisig" that is just like "addmultisigaddress" but instead of adding the multisig address/redeemScript to the wallet, returns them in a JSON object.
It also includes new unit tests for the raw transaction API argument checking code (and refactors some argument checking to remove some code duplication). |
|
|
|
Consistently getting a "TX rejected (code -22)" message when trying using sendrawtransaction. I believe I'm following all the steps properly. (createrawtransaction, signrawtransaction, sendrawtransaction)
debug.log might tell you why it is being rejected. Some reasons it might be rejected: + You're re-using an input that has already been spent. + Sum(outputs) is greater than Sum(inputs) + signrawtransaction was unable to sign all of the inputs (it did not report "complete" : true ) By the way: be EXTREMELY careful with the raw transactions API. You can easily forget to include a change output and create transactions with huge fees; test your code thoroughly on testnet before putting it into production. |
|
|
|
We need a payment protocol with non-repudiation built in. See https://gist.github.com/2217885 for a multisig version (the singlesig version is simpler, but the merchant <-> customer communication will be the same). |
|
|
|
|
Old coins are preferred over new coins because transaction spammers spend coins over-and-over again quickly to try to flood the network with transactions.
Unintentional transaction spammers (like people playing SatoshiDice over and over) accidentally do the same thing, so their transactions are given low priority and can take a long time to get confirmed.
Maybe think of it this way:
+ Transaction fees are to pay miners to include your transactions.
+ Transaction priority is used to "pay" for the network bandwith used by free transactions (note that any node relaying or listening for transactions pays the cost of every extra transaction).
|
|
|
|
In summary: the above isn't a "patch" or "git pull request" that can be submitted. This is a change of a mindset that would need to happen amongst the core development group. The GAAP isn't just a ruleset/certification that happens once and then you have it. It is an ongoing commitment.
When I hear that, I hear "you should stop doing what you're doing for a year or two or three and re-implement the whole thing." Yeah... no. As much as that would be a fun project, I don't think that is the job of the team working on the existing reference implementation. Keeping the existing software and network running as smoothly as possible is the highest priority. Another very high priority is working through issues that arise as alternative implementations happen (see the current thread in the development section about non-DER-encoded signatures for a good example). An alternative implementation that has the kind of accounting that you want is a great idea-- go do it, fund it, or convince somebody else to do it. I think genjix' libbitcoin has the "store the blockchain in a database" that you want (although last I heard he was running into performance issues with that approach). |
|
|
|
We should avoid saying "canonical" -- I just peeked at the ASN.1/BER/DER spec, and there's a "canonical" encoding that is different from the "distinguished" encoding: http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf(international standards committees seem to be completely incapable of adhering to the Keep It Simple, Stupid principle). |
|
|
|
i hope from an answer from magicaltux about an api call where i provide a txn-hash and he sends me the real deposit address back.
That would violate his users' privacy; maybe I don't want you (or the rest of the world) to know that I have a Gox account. You don't need accounts or registration, you just need a two-step process: 1) User tells you their refund address 2) You give the user a unique deposit address, and link the refund and deposit addresses in your database. To avoid creating a gazillion deposit addresses or bothering the user to give you a refund address every time, you might want to store the "user already got a deposit address" flag in a session cookie. But if the user will remember the deposit address then even that isn't necessary. |
|
|
|
0.7rc1 was running perfectly fine on Windows 7 for the past couple weeks. Just installed rc2 and it freezes on the splash screen where it says loading block index.
....
Edit: Eventually it does open. But it never used to say "Program is not responding" during the startup phase before.
Anybody else having success or failure running rc2 on Windows 7, please let us know... |
|
|
|
|
Fraud is telling people lies to get them to do something or making promises you know you can't keep.
In my humble opinion, promising people "Risk-free" returns is fraud. Even US Treasury Bills are not "risk free."
|
|
|
|
Maybe we could implement the idea of dynamic checkpoints (Gavin) but only if they come signed by the Alert signing key ...
No. Absolutely not. |
|
|
|
|
Show Posts
