|
1
|
Economy / Exchanges / Re: cryptsy hacked - bigvern on cryptsy blog
|
on: January 16, 2016, 07:07:18 PM
|
They fact that they didn't file for bankruptcy yet makes me think the story might actually be true..
Because, clearly, these are Captains of Industry 2.0: they have more identities than a drug dealer has burner phones. Wanna know why Cryptsy was the only exchange listing Lucky7Coin? Volume? No. Popularity? Bwha! No, it's was purposely installed as a measure to keep the money. IMO the only reason we're hearing from Big Vern now is because a civil suit was filed. |
|
|
|
|
2
|
Economy / Web Wallets / Re: Blockchain.info BIP32 (xpub)
|
on: December 07, 2015, 07:47:17 AM
|
I found the solution (if somebody will search). You need to use BIP44 derivation path: m/44'/0'/0' and child keys with def 0/0, 0/1, etc. instead of m/44'/0'/0'/0 & 0,1,2,etc.
I'm 99% certain you can use: m/44'/0'/0'/0/0, m/44'/0'/0'/0/1 etc |
|
|
|
|
3
|
Bitcoin / Development & Technical Discussion / Re: Pybitcointools txhash function, and SIGHASH_ALL = 0
|
on: August 10, 2015, 01:50:14 PM
|
How does this work? txh = "01000000010276b76b07f4935c70acf54fbf1f438a4c397a9fb7e633873c4dd3bc062b6b40000000008c493046022100d23459d03ed7e9511a47d13292d3430a04627de6235b6e51a40f9cd386f2abe3022100e7d25b080f0bb8d8d5f878bba7d54ad2fda650ea8d158a33ee3cbd11768191fd004104b0e2c879e4daf7b9ab68350228c159766676a14f5815084ba166432aab46198d4cca98fa3e9981d0a90b2effc514b76279476550ba3663fdcaff94c38420e9d5000000000100093d00000000001976a9149a7b0f3b80c6baaeedce0a0842553800f832ba1f88ac00000000"
>>> hexlify(bin_dbl_sha256(unhexlify(txh))[::-1])
'c99c49da4c38af669dea436d3e73780dfdb6c1ecf9958baa52960e8baee30e73'
>>>fetchtx('c99c49da4c38af669dea436d3e73780dfdb6c1ecf9958baa52960e8baee30e73') == txh
True txh is the test vector (for TxID c99c49da4c38af669dea436d3e73780dfdb6c1ecf9958baa52960e8baee30e73); Isn't that impossible? It's signing the Tx structure which has the scriptSig in it; usually the scriptSig is replaced by the scriptpubkey for signing |
|
|
|
|
4
|
Bitcoin / Development & Technical Discussion / Re: New heuristic to group addresses based on its ownership
|
on: August 07, 2015, 08:38:59 AM
|
Heuristic1: Grouping all the input addresses of transactions to the same cluster. No, because CoinJoin. Heuristic2: Grouping the change addresses (shadow addresses) to the same cluster of the input addresses.
How do you distinguish change addresses form normal outputs? What I want to do is to develop another heuristic. So far I am thinking to group addresses based on its transaction patterns. Such as peeling chain, or the addresses that distributed bitcoin to many other addresses and converge in the end. Is there any other transaction patterns that we can identify its ownership? It is just the initial idea. Any idea, advice or relative works would be appreciated  Problem is, most addresses are used only once. Especially now that pretty much every wallet is HD. How does walletexplorer.com do it? Has there been any discussions in the past? |
|
|
|
|
8
|
Bitcoin / Development & Technical Discussion / Pybitcointools txhash function, and SIGHASH_ALL = 0
|
on: August 06, 2015, 07:48:11 AM
|
pybitcointools has a txhash function which returns the singable form of a transaction, with SIGHASH appended. However the code returns a reversed hash without the appended SIGHASH bytes for SIGHASH=None, as seen here: https://github.com/vbuterin/pybitcointools/blob/master/bitcoin/transaction.py#L177-L178def txhash(tx, hashcode=None):
if isinstance(tx, str) and re.match('^[0-9a-fA-F]*$', tx):
tx = changebase(tx, 16, 256)
if hashcode:
return dbl_sha256(from_string_to_bytes(tx) + encode(int(hashcode), 256, 4)[::-1])
else:
return safe_hexlify(bin_dbl_sha256(tx)[::-1])
That doesn't seem right; is it? Also, how is a SIGHASH_ALL value of zero (rare case) calculated? (See this related SE question) Is it just changing the 00 to 01?
|
|
|
|
|
11
|
Bitcoin / Development & Technical Discussion / Validating DER sig (brainwallet Tx eg)
|
on: July 28, 2015, 12:58:12 AM
|
https://blockchain.info/tx/54a44539ada32ea5eb218ed5d853a08712be6129d8ec752b8c77f6c88bfe721aSo we have: - sha256("cat")
- sha256("password")
'01000000020fa5ed9983859c6703c5469bdda6f30ee2b59febe89d3e9755e601a35bfe837c020000007f3c303902153b78ce563f89a0ed9414f5aa28ad0d96d6795f9c6302205eff1e344551d115b708155eed631cafa4fe719be5ec68c1f3abbf8670d34e11014104a45ebc40f95cc06ef93a5f5e9daa22774a5c9a120ac14d87c328b44c1158f81cddd109246a4d8bff5f93cbba79a17f2dc6e7c73da8d6bd0d98615d1bf353f8beffffffff0fa5ed9983859c6703c5469bdda6f30ee2b59febe89d3e9755e601a35bfe837c030000007f3c303902153b78ce563f89a0ed9414f5aa28ad0d96d6795f9c6302201e74d38e5abd2836e9e17acf1b94f267b4f99704e2b22eac02ab136ec4740b76014104b568858a407a8721923b89df9963d30013639ac690cce5f555529b77b83cbfc76950f90be717e38a3ece1f5558f40179f8c2502deca11183bb3a3aea797736a6ffffffff01dc05000000000000232103d68f90ba81455256cb7a0df14fb3930d6df61393207f2f3e71659414d296e0f0ac00000000'
dersig1 = "3c303902153b78ce563f89a0ed9414f5aa28ad0d96d6795f9c6302205eff1e344551d115b708155eed631cafa4fe719be5ec68c1f3abbf8670d34e11"
dersig2 = "3c303902153b78ce563f89a0ed9414f5aa28ad0d96d6795f9c6302201e74d38e5abd2836e9e17acf1b94f267b4f99704e2b22eac02ab136ec4740b76" How, using pybitcointools (or Python), does one validate these DER sigs (given we know both privkeys)? ( PS: if someone can weigh on this related question, I'd greatly appreciate it
|
|
|
|
|
13
|
Bitcoin / Development & Technical Discussion / Using pybitcointools to validate tx_valid.json test vectors
|
on: July 27, 2015, 09:37:06 AM
|
I'm using this fork of the pybitcointools library and am trying to use the Bitcoincore JSON test vectors for unittesting. Can someone advise: 1. How ECDSA is used to verify transactions..? 2. Ideally, how pybitcointools can be used do #1 From tx_valid.json, the first test vector is: [
["The following are deserialized transactions which are valid."],
["They are in the form"],
["[[[prevout hash, prevout index, prevout scriptPubKey], [input 2], ...],"],
["serializedTransaction, enforceP2SH]"],
["Objects that are only a single string (like this one) are ignored"],
["The following is 23b397edccd3740a74adb603c9756370fafcde9bcc4483eb271ecad09a94dd63"],
["It is of particular interest because it contains an invalidly-encoded signature which OpenSSL accepts"],
["See http://r6.ca/blog/20111119T211504Z.html"],
["It is also the first OP_CHECKMULTISIG transaction in standard form"],
[[["60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1", 0, "1 0x41 0x04cc71eb30d653c0c3163990c47b976f3fb3f37cccdcbedb169a1dfef58bbfbfaff7d8a473e7e2e6d317b87bafe8bde97e3cf8f065dec022b51d11fcdd0d348ac4 0x41 0x0461cbdcc5409fb4b4d42b51d33381354d80e550078cb532a34bfa2fcfdeb7d76519aecc62770f5b0e4ef8551946d8a540911abe3e7854a26f39f58b25c15342af 2 OP_CHECKMULTISIG"]],
"0100000001b14bdcbc3e01bdaad36cc08e81e69c82e1060bc14e518db2b49aa43ad90ba26000000000490047304402203f16c6f40162ab686621ef3000b04e75418a0c0cb2d8aebeac894ae360ac1e780220ddc15ecdfc3507ac48e1681a33eb60996631bf6bf5bc0a0682c4db743ce7ca2b01ffffffff0140420f00000000001976a914660d4ef3a743e3e696ad990364e555c271ad504b88ac00000000", true] Now, we have the following:
# inputs
ins = ["%s:%d" % ("60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1", 0)] # ins = ["prevout hash:prevout index"]
# scriptPubKey of inputs
scriptPubKey = '514104cc71eb30d653c0c3163990c47b976f3fb3f37cccdcbedb169a1dfef58bbfbfaff7d8a473e7e2e6d317b87bafe8bde97e3cf8f065dec022b51d11fcdd0d348ac4410461cbdcc5409fb4b4d42b51d33381354d80e550078cb532a34bfa2fcfdeb7d76519aecc62770f5b0e4ef8551946d8a540911abe3e7854a26f39f58b25c15342af52ae'
outs = [{'value': 1000000, 'script': '76a914660d4ef3a743e3e696ad990364e555c271ad504b88ac'}]
raw = mktx(ins, outs)
# "0100000001b14bdcbc3e01bdaad36cc08e81e69c82e1060bc14e518db2b49aa43ad90ba2600000000000ffffffff0140420f00000000001976a914660d4ef3a743e3e696ad990364e555c271ad504b88ac00000000"
# from test_vector ()or fetching the Tx: 23b397edccd3740a74adb603c9756370fafcde9bcc4483eb271ecad09a94dd63:0)
signed = "0100000001b14bdcbc3e01bdaad36cc08e81e69c82e1060bc14e518db2b49aa43ad90ba26000000000490047304402203f16c6f40162ab686621ef3000b04e75418a0c0cb2d8aebeac894ae360ac1e780220ddc15ecdfc3507ac48e1681a33eb60996631bf6bf5bc0a0682c4db743ce7ca2b01ffffffff0140420f00000000001976a914660d4ef3a743e3e696ad990364e555c271ad504b88ac00000000"
der_sig = "0048304402203f16c6f40162ab686621ef3000b04e75418a0c0cb2d8aebeac894ae360ac1e780220ddc15ecdfc3507ac48e1681a33eb60996631bf6bf5bc0a0682c4db743ce7ca2bab01" # NOTE: this signature is not canonical because both the r and s values have the highest bit set (ie ideally r and s should be padded with nullbytes)
So given all the information from the test vectors, how does one verify the signature against the raw transaction? (NB. I'm doing this as a means to learn the way Bitcoin signs/verifies transactions. So far I've had no issue with these unittests) |
|
|
|
|
14
|
Bitcoin / Development & Technical Discussion / Re: Using Pycoin to spend non-standard scripts
|
on: July 21, 2015, 04:15:28 AM
|
Basically you have to override sign(tx,i,priv,hashcode) You want to change line 341 of transaction.py so that it accepts an input script. You need to feed it the scriptPubKey of the UTXO you are spending. signing_tx = signature_form(tx, i, '<utxo_scriptPubKey>', hashcode) Then you need to sign the transaction with pubkey 042d...d17c, and copy the sig into "sig1", then sign the transaction with pubkey 0330...f63f, and copy the sig into "sig2". Finally your non-standard scriptSig is: <sig1>
<sig2> I've done it on the "Hello World" example I did above, but the code is kinda ugly. Let me clean it up and I'll write a pybitcointools implementation to spend the coin. Ah ha! OK, that makes perfect sense. I'll try it out. There's a fork of pybitcointools which is updated more often here. One of the issues I've encountered with pybitcointools is the DER encoding; the fork checks for DER encoding, whereas the original pybitcointools isn't even BER in some instances (eg if the r or s value has the leading bit set and is less than 2**255, the encoding doesn't prepend nullbytes) |
|
|
|
|
15
|
Bitcoin / Development & Technical Discussion / Re: Using Pycoin to spend non-standard scripts
|
on: July 21, 2015, 03:15:40 AM
|
Maybe we can work on this Tx: http://test.webbtc.com/tx/2e7f518ce5ab61c1c959d25e396bc9d3d684d22ea86dc477b1a90329c6ca354fI've set up the script like this: OP_IF
0330ed33784ee1891122bc608b89da2da45194efaca68564051e5a7be9bee7f63f
OP_CHECKSIGVERIFY
OP_ELSE
80bf07
OP_NOP2
OP_DROP
OP_ENDIF
042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9
OP_CHECKSIG So its a master key, which is sha256("master"*42) How would I use pybitcointools to spend this script? Nb script: myscript = "63210330ed33784ee1891122bc608b89da2da45194efaca68564051e5a7be9bee7f63fad670380bf07b1756841042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9ac"
|
|
|
|
|
17
|
Bitcoin / Development & Technical Discussion / Re: Using Pycoin to spend non-standard scripts
|
on: July 20, 2015, 09:09:31 AM
|
Yep... there is a bug in there somewhere... Try the following from bitcoin import *
serialize_script(deserialize_script('ac'))
---
RuntimeError: maximum recursion depth exceeded while calling a Python object
Yeh, I often run scripts on iOS Pythonista, and there's a lot of recursion errors that come up since by default the recursion depth is 256; so setting sys.setrecursiondepth(512) often works in that environment. The pybitcointools bug is strange because the code serializes multisig scripts, but there's a bug with the CHECKMULTISIG; so instead of serializing the 'ae', it just appends 'ae' to the end of the returned string. I am looking at using this code: def mk_script(*args):
# lst = ['76', 'a9', '14', 'dd6cce9f255a8cc17bda8ba0373df8e861cb866e', '88', 'ac']
if len(args) == 1 and isinstance(args[0], (list, tuple))
lst = list(args[0])
elif len(args) > 1 and all(map(lambda o: isinstance(o, str), args)):
lst = [args]
else:
lst = [changebase(str(x), 10, 16, 2) if isinstance(x, (int, long)) else x for x in args]
llens = [len(changebase(x, 16, 256, 1)) for x in lst] # byte lengths
lint = map(lambda h: decode(h, 16), lst) # list as ints
asm = 0xff
for i in range(len(lint)):
asm = asm << (8*llens[i]) | lint[i]
asmhex = "0x" + encode(asm, 16, (sum(llens) + 1)*2)
final = asmhex.partition('0xff')[-1]
return final How would I go about tweaking this code to avoid the manual addition of push20? ie. I want to use mk_script(['76', 'a9', 'dd6cce9f255a8cc17bda8ba0373df8e861cb866e', '88', 'ac']) ... instead of mk_script(['76', 'a9', '14', 'dd6cce9f255a8cc17bda8ba0373df8e861cb866e', '88', 'ac']) (note the "14" preceding the pubkeyhash, which acts as push 20 bytes). I'd prefer to avoid using the push bytes |
|
|
|
|
18
|
Bitcoin / Development & Technical Discussion / Re: Using Pycoin to spend non-standard scripts
|
on: July 18, 2015, 08:49:12 AM
|
I never realized there was a serialize_script method. I was simply thinking of the serialize(tx_dict). I was thinking you would right your own (or overwrite) the serialize_script method. I mean there are less than 100 op codes right?[/size] Yeah, that's certainly do-able. I'll fork the pybitcointools library and see how I go with it. I've been looking at Peter Todd's python-bitcoinlib and Richard Kiss' Pycoin, mainly because the classes are much more powerful for playing around with scripting, SIGHASH, etc. That being said, the OOP for python-bitcoinlib tries to emulate the Core software naming conventions, and it's really complicated. If anyone else can provide a single example of a non-standard script Tx using Pycoin/python-bitcoinlib, I'd really appreciate it. d4n13: Thanks for the input, I'll look at trying this with pybitcointools |
|
|
|
|
19
|
Bitcoin / Development & Technical Discussion / Re: Using Pycoin to spend non-standard scripts
|
on: July 18, 2015, 06:41:04 AM
|
How would I use Pycoin to play around with non-standard scripts like this? Alternatively, pybitcointools.
Writing a Script "compiler" in python should be very straight forward. PyBitcoinTools will parse out the scripts with deserialize, then you take the Script 'asm' and write a decompiler. If you then put the 'asm' data back in the dict and serialize with pybitcointools you should be good to go. Thanks for the reply! I'm really familiar with pybitcointools, so I can certainly see how your suggestion works. However, the issue is when using serialize_script; namely, if you've got objects (like a pubkey), the serialize_script method doesn't add push codes for the size of the object. Ie: my_script = serialize_script([OP_foo, OP_bar, "20byte_pubkey_hash", OP_spam])
myscript will return 11 22 01234567890123456789 33 instead of 11 22 14 01234567890123456789 33 |
|
|
|
|
Show Posts
