Bitcoin Forum
May 09, 2016, 01:01:38 AM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 114 »
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).
482  Other / Off-topic / Re: Find Satoshi on: September 14, 2012, 02:08:36 AM
Yeah, not Satoshi.  Satoshi has red hair and a big handlebar moustache.
483  Alternate cryptocurrencies / Altcoin Discussion / Re: Decrits Proposal: Solution for an unbound, energy-related, stable value currency on: September 14, 2012, 01:58:18 AM
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"?
484  Bitcoin / Development & Technical Discussion / Re: Version 0.7.0 release candidate 3 ready for testing on: September 13, 2012, 06:42:40 PM
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 
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:
Code:
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'}]}
486  Bitcoin / Development & Technical Discussion / Re: [ALPHA] Double signed wallet with a patternlock on: September 11, 2012, 10:21:28 PM
You would have probably found that a lot quicker running a testnet version.

The testnet Faucet is giving away 500 play bitcoins at a time right now:
  http://testnet.freebitcoins.appspot.com/
487  Bitcoin / Development & Technical Discussion / Re: Transaction metadata (do we need an OP_DROP transaction type?) on: September 10, 2012, 08:34:53 PM
Productive discussion in IRC today:
   http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/09/10#l4463724

Executive summary: Good idea, Stefan.  Lots of details to be worked out...
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:

Quote
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?
489  Bitcoin / Development & Technical Discussion / Re: Version 0.7.0 release candidate 2 ready for testing on: September 10, 2012, 05:39:43 PM
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.
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/1818

Quote
This 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.
492  Bitcoin / Legal / Re: Bitcoin he-said she-said, or, will digitally signed payment requests be needed? on: September 10, 2012, 12:22:11 AM
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).
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).
495  Bitcoin / Development & Technical Discussion / Re: Non-canonical signatures: looking for detectives on: September 08, 2012, 05:09:59 PM
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).
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.

497  Bitcoin / Bitcoin Discussion / Re: Use of countries to grab more entropy for brain wallets on: September 07, 2012, 11:32:31 PM
See http://dl.acm.org/citation.cfm?id=2335366 for recent research on passphrase usability; results do not look good. http://scholar.google.com/scholar?q=passphrase to see what other researchers have tried.
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...
499  Economy / Long-term offers / Re: ★ VESCUDERO's Risk-free Weekly Term deposits at 1.5% ★ on: September 07, 2012, 05:58:15 PM
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."
500  Bitcoin / Development & Technical Discussion / Re: New vulnerabilities in the advent of off-the-shelf ASIC mining on: September 07, 2012, 02:17:04 PM
Maybe we could implement the idea of dynamic checkpoints (Gavin) but only if they come signed by the Alert signing key ...
No. Absolutely not.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 114 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!