|
For option 2 do you mean the nonce would be something like HASH(1), HASH(2), HASH(3)........?
So why not simply use 1, 2, 3...... as the pubkey?
|
|
|
|
|
You use mtgox "to transfer relatively large amounts of money" without using google authentication (you don't need to order a yubikey)? Your loss is deserved
|
|
|
|
Guys, I just requested a wire xfer this morning (Gox screenshot)Funds gone from MtGox, will post if they get to bank in 2-4 days... I hope so!! Also I hope I get the bounty if it goes through because my bank charges $40 for receiving intl. wires  Thanks! Thanks for testing although sorry to say you should not have posted the exact amount and bank name in the screenshot. You could have covered those details NOW and send them LATER in full after (if) the wire arrives instead. Why? Because there is enough identifying information for Gox to locate you and "manually" wire you the amount (which is not a round number). Now you may end up (maybe) receiving the bounty and still not proving anything. If it works like this, everyone will just post there screenshot here |
|
|
|
I would like to clarify the meaning of different hashtypes: SIGHASH_ALL: All inputs and outputs are required. SIGHASH_ALL + SIGHASH_ANYONECANPAY: All outputs are required. I don't care where the rest of bitcoins come from. SIGHASH_NONE: All inputs are required. I don't care where the bitcoins go. SIGHASH_NONE + SIGHASH_ANYONECANPAY: I don't care where the rest of bitcoins come from. I don't care where the bitcoins go. Basically throwing the coins away without any condition. SIGHASH_SINGLE: All inputs are required. As long as one particular output is satisfied, I don't care where the rest of bitcoins go. SIGHASH_SINGLE + SIGHASH_ANYONECANPAY: I don't care where the rest of bitcoins come from. As long as one particular output is satisfied, I don't care where the rest of bitcoins go. Am I correct? How is the particular output in SIGHASH_SINGLE specified? I don't understand the description in bitcoin wiki ( https://en.bitcoin.it/wiki/OP_CHECKSIG#Procedure_for_Hashtype_SIGHASH_SINGLE ) |
|
|
|
You know OP_CHECKCOLORVERIFY can be implemented more usefully by adding op-codes to let scripts analyze the txouts of the transactions spending them. I
That's true. However, the current script system is greatly restricted by the standard transaction rules (and the fact that some opcodes are disabled). The problem is that the system requires analysis of all inputs and other outputs. You need to add the values together. OP_PUSH_INPUTS: This would push all the inputs on to the stack <value> <script> <value> <script> ... <value> <script> <number of inputs> OP_PUSH_OUTPUTS: This would push all the outputs on to the stack <value> <script> <value> <script> ... <value> <script> <number of other outputs> <index of this output> You need the "splice" opcodes to be enabled to actually manipulate the results. However, that is a huge amount of overhead. Another issue is that the system assumes that if <hash> OP_CHECKCOLOR is in an output script, that is proof that the output is a specific color. I think we could have a more generic code called OP_META, which is OP_NOP3 for old clients. A typical case would look like: <serialized script> OP_META OP_DROP OP_DUP OP_HASH160 <address> OP_EQUALVERIFY OP_CHECKSIG OP_META will dictate the validity of the whole transaction. Old clients will ignore <serialized script> OP_META OP_DROP. New clients will run the serialized script. So we can include whatever new OP codes we want without breaking old clients. This will also solve the problem of SIGHASH_WITHINPUTVALUE in a soft-fork ( https://bitcointalk.org/index.php?topic=181734.20) I don't know much about zerocoin but I suspect OP_META will be useful for it too Going to have meal now. Will give more details later |
|
|
|
You know OP_CHECKCOLORVERIFY can be implemented more usefully by adding op-codes to let scripts analyze the txouts of the transactions spending them. It'd be useful for a lot more than colored coins, and frankly there is no way in hell you are going to get a colored-coin-specific opcode included in Bitcoin.
I'd suggest you think about how a more general solution could work.
Thanks for your comment. I will think about it. At least, does my proposal technically work? |
|
|
|
It requires a soft-fork. As long as a vast majority of miners (e.g. >75%) follow the new rules, there won't be any prolonged fork. At that time, the market force will make the minority to reject invalid OP_CHECKCOLOR transaction or they will get orphaned. See how v2 block was gracefully implemented: https://en.bitcoin.it/wiki/BIP_0034Right, and that change has a "point of no return". Your target is to propose an upgraded transaction type right? That makes voting a little more difficult. Maybe, propose a block type 3 that accepts transaction type 2. If more than 75% of the last 1000 blocks are type 3 or higher, then reject blocks containing invalid OP_CHECKCOLOR transactions If more than 95% of the last 1000 blocks are type 3 or higher, then reject any blocks of type less than 3, forever afterwards. OP_CHECKCOLOR compatible clients (both mining and non-mining nodes) will never create, relay, or mine invalid OP_CHECKCOLOR transactions. Before 75% of miners enforce the new rules, they will still accept blocks with invalid OP_CHECKCOLOR transactions to avoid a prolonged fork. However, they will not acknowledge the color in these invalid OP_CHECKCOLOR transactions. And yes, SPV clients won't work in this sub-optimal situation.
Right, the point of the change to make miners support it. +1 Is my understanding of your process correct?
Minting
Input (1 BTC): from "some-output"
Output (1 BTC): Hash("some output") OP_CHECKCOLOR ....
To be precise, it is "script of some-output" (see transaction a0eecca313623fb39ddf92ed36782ec58003fec049d8395166b459bfbbfa3e7a on testnet as a minting example) The risk of color collision would be similar to address collision, which could be neglected Transfer
Input (1 BTC): from the previous transaction (Hash("some output") OP_CHECKCOLOR ....)
Output1 (0.5 BTC): Hash("some output") OP_CHECKCOLOR ....
Output2 (0.5 BTC): Hash("some output") OP_CHECKCOLOR ....
So, effectively OP_CHECKCOLOR does both checking for minting and checking for spending.
Yes. I can't think of a case which minting and spending need different code Transaction Checking
It is nice that the colour is stored in the sig script of the output. That way it can be done as a local check for the transaction.
Something like:
If normal processing of the transaction where OP_CHECKCOLOR is a NOP fails, then the invalid transaction.
Scan all output scripts for the OP_CHECKCOLOR script
1. If OP_CHECKCOLOR occurs twice in any output then invalid transaction
2. If any OP_CHECKCOLOR is not preceded by a 20 byte array, then invalid transaction
3. All colored outputs are marked as the color of the byte array
4. Determine total value of outputs for each color
4.1. Scan input scripts,
4.1.1. find the corresponding output script
4.1.1.1. If it contains <color> OP_CHECKCOLOR somewhere, then the input is of that color
4.1.1.2. If hash(output) is equal to <color>, then the input is of that color
4.1.1.3 Credit that color with the value of the input
4.2. If the total outputs for a particular color is greater than the inputs, then invalid transaction
1. We may or may not allow multiple OP_CHECKCOLOR in one output. If it is allowed, we can have mixed colored coin, which could be de-mixed in the next transaction. 2. If any OP_CHECKCOLOR is not preceded by a 20 byte array and followed by OP_DROP, then invalid transaction. It is for backward compatibility 3. Yes 4.1.1.1. Do you mean spending here? 4.1.1.2. Do you mean minting here? 4.1.1.3. Yes if it is spending colored coin. There is no restriction for the value in minting. For example, I have 1 normal BTC in address xxx, and 1 normal BTC in address yyy. I can mint at most 2 Hash(xxx)-color BTC in one transaction. This will make minting more effective. Otherwise, I have to send 1 BTC from yyy to xxx first, before I could mint 2 Hash(xxx)-color BTC |
|
|
|
Although a code change would be simple any changing of the fee rules is likely to result in all sorts of "end of the world" topics being created so I somehow doubt this is going to occur any time soon.
After considering this for a while (and noticing the SD *bet* that this *spammer* included) it could actually be an attack *at* SD (as it will presumably always have higher priority than some random SD bet so it is maybe some sort of attempt to *slow down* SD although on its own of course will be rather ineffective).
In any case if all it is doing is taking the place of some SD tx that would otherwise get in the block then it really isn't actually making any difference to your disk usage at all (you would be storing the bytes either for SD or for this SB and in fact as SB txs are tiny then you may actually be benefiting slightly from SB).
The 0.00005430 restriction is more aggressive than mine |
|
|
|
The original SIGHASH_WITHINPUTVALUE idea, unfortunately, requires a hard-fork because there is no room to inject extra data when signing. I have a soft-fork proposal for this called OP_CHECKVALUE |
|
|
|
Sorry but I don't get this bit - the party we are talking about has not paid *any* fee to move his 300 BTC around hundreds (or is it thousands) of times. Ah, I thought you were talking about the party creating 0.001 value txouts to (presumably) deanonymize people. I don't see what your concern is with the 300 BTC party. Their transactions are handled in priority order, and higher priority free transactions still have first dibs on the limited free space. That they're moving a large amount just means that they meet the minimum threshold after one block— but it doesn't give them a particularly high priority. The resulting load is all prunable and doesn't hurt the privacy of third parties, so I don't see a reason to be especially concerned by it. It is prunable but the reference client is not pruning and all these craps fill my harddrive. It will also take more time for initial download. I hope the core dev will tighten the default fee rules to stop such attack. Just modify the default priority formula from : priority = sum(input_value_in_base_units * input_age)/size_in_bytes to priority = sum( min(5000000000, input_value_in_base_units) * (input_age - 1))/size_in_bytes will slow down such stupid attack a lot, without affecting legitimate use (legitimate users can pay 0.0001 fee if they want fast confirmation) |
|
|
|
A security researcher has predicted SHA 256 will be cracked this year. When that happens the algorithm may change.
Cite? There are not even any "academic attacks" against SHA-2 at this time. An academic attacking being a method which is faster than brute force but still computationally infeasible to exploit in the real world. Just nonsense. The blockchain is still safe even it uses MD5(MD5()). The difficulty will adjust. Actually, a weakened SHA256 gives advantage to GPU mining because ASICs are not programmable. |
|
|
|
Therefore, OP_CHECKCOLOR does not really need to modify anything on the stake. When it comes to validation of individual signature, OP_CHECKCOLOR is nothing more than OP_NOP1
Would this mean that clients that interpret OP_NOP1 as OP_CHECKCOLOR would reject transactions that others accept? Yes. (To avoid confusion, I changed it to OP_NOP3 as some previous BIPs has proposed on OP_NOP1 and OP_NOP2) If yes, a block containing such transaction forks between those clients.
It requires a soft-fork. As long as a vast majority of miners (e.g. >75%) follow the new rules, there won't be any prolonged fork. At that time, the market force will make the minority to reject invalid OP_CHECKCOLOR transaction or they will get orphaned. See how v2 block was gracefully implemented: https://en.bitcoin.it/wiki/BIP_0034If not, then this is just an annotation on the transaction that does not prove that the colored coin can be traced back to its genesis, therefore SPV clients can not rely on the color indicated.
OP_CHECKCOLOR compatible clients (both mining and non-mining nodes) will never create, relay, or mine invalid OP_CHECKCOLOR transactions. Before 75% of miners enforce the new rules, they will still accept blocks with invalid OP_CHECKCOLOR transactions to avoid a prolonged fork. However, they will not acknowledge the color in these invalid OP_CHECKCOLOR transactions. And yes, SPV clients won't work in this sub-optimal situation. |
|
|
|
Because the Bitcoin community is just going to lay down for the ASIC's, the migration of the GPU's to Scrypt just guarantees that the Altcoins will be replacing Bitcoin in the next 1 to 2 years. What is going to happen is that the first gen ASIC market (everything out now, and about to come out) will mainly be held in a couple of big players hands. You'll have some expansion to the masses, but your talking minor diversification. The next gen ASICs which are in development now (which is on a magnitude better than the first gen), won't be sold to the public. They will be held in private hands, the same hands that are developing them. And that will be the end of it, it will be all centralized in two or three hands. That is how Bitcoin dies. I hope I'm wrong, really I do. I've been a Bitcoin fanboy since I got into it in early 2011.
I just hope that the Altcoins will stand up and fight the upcoming Scrypt-ASICs, unlike the Bitcoin community.
Full disclosure: My GPU farm is pointing to Litecoin, for the past month and I do have ASICs on order.
If you think it's a good idea, just create your Bitcoin-Scrypt fork and ask people to follow it |
|
|
|
I am trying to create a transaction to implement my proposed color coin protocol. Test-net transaction id is a0eecca313623fb39ddf92ed36782ec58003fec049d8395166b459bfbbfa3e7a . The output script is bc0167de574bfa6c2e04af2b80bf2717399ec614 OP_NOP3 OP_DROP OP_DUP OP_HASH160 ef8a580d4a2f946cf9bb4c18cee113061ffe1912 OP_EQUALVERIFY OP_CHECKSIG Where bc0167de574bfa6c2e04af2b80bf2717399ec614 = RIPEMD160(SHA256(76a914a42f15b5fd15552aa14973bfc59039fbc095580488ac)) and 76a914a42f15b5fd15552aa14973bfc59039fbc095580488ac is the script of the previous output The new script is, of course, non-standard but it should act exactly like a normal pay-to-pubkey-hash transaction. Then, I use this command to create a raw transaction to spend to colored coin: bitcoind --testnet createrawtransaction '[{"txid":"a0eecca313623fb39ddf92ed36782ec58003fec049d8395166b459bfbbfa3e7a","vout":0}]' '{"n1mkYwsdnQap2fcHrzoiZQgxceKFkVrrER":1.78}'and bitcoind returns: 01000000017a3efabbbf59b4665139d849c0fe0380c52e7836ed92df9db33f6213a3cceea00000000000ffffffff0180109c0a000000001976a914de2ef3cd43d270c9aba0c165fc9dc0a8ed0148cc88ac00000000 I try to use signrawtransaction to sign it, and unsurprisingly, bitcoind fails to sign. Is there any easy way to sign the transaction? (The public key is 03D8D93A4F4BF9628742D2C580E83508941474A924A24F5A4339AE0AD200F2B3FD) |
|
|
|
One of the problems I have with the alt clients, I don't know if Armory does this, but it seems that many of them use the same address for change every time.
That's a problem because if someone is able to identify any address with me, it then is possible for them to figure out what address was used as change when the input for that address was spent. And if the change address is the same every time, it's game over, they now can identify all kinds of addresses I sent money to and sent money from.
That's the primary reason I'm sticking with bitcoin-qt. It uses fresh change address each time change is needed.
Armory does not reuse address by default |
|
|
|
They are changing SWIFT code How was this communicated to you? When does the change go into effect? Just login mtgox and you will see it. I think changed for a few days |
|
|
|
|
They are changing SWIFT code from MHBKJPJT (Mizuho Bank) to MHCBJPJT (Mizuho Corporate Bank)
What's the implication?
|
|
|
|
When signing with ECDSA you need to include a random number, which makes the signature different.
Okay - so random number rather than timestamp - the point is you *can* embed information then (and if random number then easier probably as perhaps if it was a timestamp it might be checked for range). Of course I assume it is not that big so not much information can be sent with such an approach (yes - too lazy to check the exact details as I don't think it matters very much - if the wish is to send messages then Bitmessage would be a much better option). No, the random number is a secret. You can't use it to store information. Revealing the random number will also reveal the private key. http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_generation_algorithm |
|
|
|
There is no timestamp in transaction
So what is the thing that makes an identical tx different each time you sign it (I have tested this so I know it to be a fact)? When signing with ECDSA you need to include a random number, which makes the signature different. There is no timestamp in transaction. Check the protocol. |
|
|
|
|
Show Posts
