|
481
|
Economy / Service Announcements / Re: Blockchain.info - Bitcoin Block explorer & Currency Statistics
|
on: September 14, 2012, 04:47:00 PM
|
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). |
|
|
|
|
485
|
Bitcoin / Technical Support / Re: request: decoderawtransaction in python
|
on: September 12, 2012, 08:25:14 PM
|
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'}]}
|
|
|
|
|
488
|
Bitcoin / Development & Technical Discussion / Transaction metadata (do we need an OP_DROP transaction type?)
|
on: September 10, 2012, 06:25:20 PM
|
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? |
|
|
|
|
490
|
Bitcoin / Development & Technical Discussion / Re: [Bug] signrawtransaction of multisig with explicit privkey doesn't work
|
on: September 10, 2012, 01:58:46 PM
|
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). |
|
|
|
|
491
|
Bitcoin / Development & Technical Discussion / Re: Version 0.7.0 release candidate 2 ready for testing
|
on: September 10, 2012, 12:56:19 PM
|
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. |
|
|
|
|
493
|
Bitcoin / Development & Technical Discussion / Re: Transaction fee logic
|
on: September 09, 2012, 04:03:09 PM
|
|
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).
|
|
|
|
|
494
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin Project will be making a major announcement in September
|
on: September 08, 2012, 05:20:44 PM
|
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). |
|
|
|
|
496
|
Bitcoin / Development & Technical Discussion / Re: best way to "instant send back"
|
on: September 08, 2012, 03:22:28 PM
|
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. |
|
|
|
|
498
|
Bitcoin / Development & Technical Discussion / Re: Version 0.7.0 release candidate 2 ready for testing
|
on: September 07, 2012, 09:52:12 PM
|
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... |
|
|
|
|
Show Posts
