|
342
|
Other / Off-topic / Re: New largest number factored on a quantum device is 56,153
|
on: November 29, 2014, 05:31:14 PM
|
The title of the article is quite misleading IMO. The experiment is not new. It was made in 2012. Very roughly, the idea is that when two numbers are multiplied, their digits are combined. We know the product, so this gives a set of equations. If the target has a particular bit pattern, the equations reduce and can be solved as the minimisation of a function. The minimization is ran on a quantum NMR computer. The original team factored 143, the new discovery is that there are higher numbers that exhibit a similar pattern and thus can be solved with the same apparatus. It is not a general purpose algorithm for factorization. And It's not Shor's algorithm. The largest number is still 15 for it. ECC doesn't use prime number factorisation. It is subject to a modified version of Shor's algorithm but would still require ~1000 q bits. References http://arxiv.org/pdf/quant-ph/0301141v2.pdfhttp://arxiv.org/pdf/1411.6758.pdf |
|
|
|
|
344
|
Bitcoin / Development & Technical Discussion / Re: help transforming signed tx to unsigned for OP_CHECKSIG
|
on: November 27, 2014, 06:12:07 PM
|
If that last 0x00 byte isn't part of the var_int length, what purpose does it serve? I can't for the life of me identify its function. And other tx's less than size 0xfd don't seem to have that 00 after the size.
The 0x00 is the opcode for OP_0, it pushes an empty array on the stack. Your raw tx is 0100000001d3988ed76ff725847e4fdfb2d51b58881a94d7b5319ac1a9951bf9532e98a85d00000000fdfe000048304502210080f029908a2d92186d6f174acc8a27e763c17bb4ad4a4d0f9e0e9040687a0aa6022024ad5d27a1a166a657c5df283e00cccfd17cfd8e0d841eb9698f56fcd5ae08e201483045022100a91a362a0471d40fa31b1dc0d2decde9a6f8bc6d952025523430c60de39855c8022023340bbd96c30391bd70cff12926c7f540d5dbb52adcc0c604b2df43bb686b7b014c6952210252865fa8553e7314deaa058b45349969a53df2a4825a9e8ba314236fe6bfd6c4210395ad4c60c648dea133e3731f2a0583baf1da5f6c60b56cdbad3b3bf8d28fe7de21021f3affcf31dee6b2ed6cb375d382516fd1fcb78f96dbeb6ceacc9aa47c6f386153aeffffffff01b8bb0608000000001976a9148442e8244ee26488bdef062b77a727053372a65488ac00000000
On https://blockchain.info/tx/0700ef4799c28537e7ae494575a2fa41bb2354ce621245dee796cfd7cdb3ddef?show_adv=true, the input script is OP_FALSE 304502210080f029908a2d92186d6f174acc8a27e763c17bb4ad4a4d0f9e0e9040687a0aa6022024ad5d27a1a166a657c5df283e00cccfd17cfd8e0d841eb9698f56fcd5ae08e201 3045022100a91a362a0471d40fa31b1dc0d2decde9a6f8bc6d952025523430c60de39855c8022023340bbd96c30391bd70cff12926c7f540d5dbb52adcc0c604b2df43bb686b7b01 52210252865fa8553e7314deaa058b45349969a53df2a4825a9e8ba314236fe6bfd6c4210395ad4c60c648dea133e3731f2a0583baf1da5f6c60b56cdbad3b3bf8d28fe7de21021f3affcf31dee6b2ed6cb375d382516fd1fcb78f96dbeb6ceacc9aa47c6f386153ae
This asm part shows you that 4 values were pushed. - <nothing>
- 304502210080f029908a2d92186d6f174acc8a27e763c17bb4ad4a4d0f9e0e9040687a0aa602202 4ad5d27a1a166a657c5df283e00cccfd17cfd8e0d841eb9698f56fcd5ae08e201
- 3045022100a91a362a0471d40fa31b1dc0d2decde9a6f8bc6d952025523430c60de39855c802202 3340bbd96c30391bd70cff12926c7f540d5dbb52adcc0c604b2df43bb686b7b01
- 52210252865fa8553e7314deaa058b45349969a53df2a4825a9e8ba314236fe6bfd6c4210395ad4 c60c648dea133e3731f2a0583baf1da5f6c60b56cdbad3b3bf8d28fe7de21021f3affcf31dee6b2 ed6cb375d382516fd1fcb78f96dbeb6ceacc9aa47c6f386153ae
The "" is a dummy value because there is a legacy off-by-1 bug in OP_CHECKMULTISIG that makes it use 1 more stack element than it should. The other two beginning with 30 are the 2 sigs in DER format. The last one is your redeem script. If you take it and run it through SHA-256 then RIPEMD-160, you'll get a2d92e95e73732e01aea6a4d7c4e406813ea32be which matches the expected hash160. http://www.fileformat.info/tool/hash.htm. Also if you decode it with bitcoin core console decodescript 52210252865fa8553e7314deaa058b45349969a53df2a4825a9e8ba314236fe6bfd6c4210395ad4c60c648dea133e3731f2a0583baf1da5f6c60b56cdbad3b3bf8d28fe7de21021f3affcf31dee6b2ed6cb375d382516fd1fcb78f96dbeb6ceacc9aa47c6f386153ae

{
"asm" : "2 0252865fa8553e7314deaa058b45349969a53df2a4825a9e8ba314236fe6bfd6c4 0395ad4c60c648dea133e3731f2a0583baf1da5f6c60b56cdbad3b3bf8d28fe7de 021f3affcf31dee6b2ed6cb375d382516fd1fcb78f96dbeb6ceacc9aa47c6f3861 3 OP_CHECKMULTISIG",
"reqSigs" : 2,
"type" : "multisig",
"addresses" : [
"1D4LM66YwaoqcfHF1366pqvxvxHxvq66EZ",
"12KVX5eJQZDgZcccWnJNcuHgxgSdd3s8yT",
"1K1VgVpscuYr2j1C8D3F7BrghSpitdg2t9"
],
"p2sh" : "3GY5ZgtAeJDkiMLDR2DwSXFexVWJPnfA6g"
}
It's a 2 of 3 multi sig. It is also the pub script that you should use as the input when preparing the signature. Because at the time CHECKSIG/MULTISIG gets evaluated, the current script is that one. The OP_HASH160 xxx OP_EQUAL was evaluated before and is no longer relevant. |
|
|
|
|
345
|
Bitcoin / Development & Technical Discussion / Re: help transforming signed tx to unsigned for OP_CHECKSIG
|
on: November 27, 2014, 01:29:01 PM
|
It's a pay to script hash. They work differently than other transactions. Here's a play by play example: https://gist.github.com/gavinandresen/3966071 and a link to the BIP https://github.com/bitcoin/bips/blob/master/bip-0016.mediawikiBasically, the protocol has a special case for scripts of the form OP_HASH160 xxxx OP_EQUAL. Note that there is no CHECKSIG here because it's you who provides the pubscript and it has to hash to the given hash. It's hard to explain in a short post but the links should give you enough information. If not, feel free to ask. Additionally, in the original tx, the var_int for the script size is 0xfdfe0000, which means the size is 0xfe, but by my count, the size looks like 0xfd. Can you possibly point out to me why the var_int is one byte larger than I think it should be?
The size is indeed 0xfe. 0xFD is followed by 2 bytes for the length FE00. You probably thought that the 2nd 00 was part of the length but it's actually the first byte of the script. |
|
|
|
|
346
|
Bitcoin / Development & Technical Discussion / Re: Peer-To-Peer Discussion, How Events Play Out.
|
on: November 27, 2014, 06:02:49 AM
|
This should be of value to you if you haven't seen it already: https://en.bitcoin.it/wiki/Protocol_specification2. Downloading the Blockchain:
- When my client (node) requests pieces of the blockchain (from my node's peers), how does this play out?
You request data with 'getdata' passing an inventory vector, basically a hash + type. Blocks are returned as 'block' messages. You can ask for many blocks at once, but they will come back as separate messages. 4. Do Nodes Request More Peers from other Peers?
- So do nodes ask other peers for their peer list, to expand their own peer list?
- In other words, is it self expanding, or do I have to manually add more peers?
You can proactively ask for peers with the 'getaddr' request or they may be given to you anyway with the 'addr' message. To bootstrap, there is a hardcoded list of DNS servers specially setup to deliver peer addresses. 5. Is my Node Being Sent New Transactions (that are not processed)?
- So is my node being sent the thousands of new transactions that have not been processed yet (i.e. put into a block)?
- Or is there something else happening here?
They are sent to you as 'tx' messages if they are being relayed (live). However, if you connect to a peer and want to see the tx that it has unconfirmed, you must send a 'mempool' message. 6. Right Now, What Data is Being Sent to My Running Node?
- So what data right now is being sent to my node (I'm running the standard Bitcoin WIN Client/Node), I know there is new blockchain data, but what else?
If you don't ask for anything and no one ask you anything, passively you can get: inv, addr, tx, ping and alert. 7. Is there Any Know P2P Structures that Bitcoin is modeled after?
- What P2P structure is Bitcoin modeled after, is it like a gossip style model or something else entirely?
Similar but different clients have different strategies. The protocol doesn't spec out this aspect. AFAIK, the reference client requests from a single peer but relays to many. |
|
|
|
|
348
|
Bitcoin / Bitcoin Discussion / Re: 3 Bitcoin Doomsday Scenarios I can't find much discussion on...
|
on: November 23, 2014, 05:46:51 AM
|
ad 1.
That is not how Bitcoin/cryptography works. You can't sign transaction with some kind of master key
I'm not talking about a crypto backdoor here but a backdoor in the implementation. For instance, in CheckSig (interpreter.cpp), if (vchSig.empty())
return true;
Of course, this one is super obvious and won't fool anyone but let's say that something similar has been slipped in voluntarily or not. If enough of the network is running the same code base (and the reference client dominates at the moment), one could create a big fork. On the other hand, this part of the code is very sensitive and lots of people have looked at it. It would have to be quite subtle. Once they use the backdoor, it will be noticed and patched very quickly. The coins should return to their real owner then. ad 2.
On a mathematical level cryptography is safe, unless it is a conspiracy that involves all mathematics and they just lied to us for decades.
Not all mathematicians would have to be involved. Again, the Enigma machine is an interesting historical precedent. Besides, it's enough to have an evil genius who cracks it. It's unlikely to happen because when the community gets close to a solution, the method is deemed unsafe and replaced like SHA-256 replaced SHA-1. You would have to crack various cryptography functions too. ad 3.
For offline signing you would need some secret wireless transmitter, that does send the key. That would be some real hard core conspiracy.
It's not a secret wireless transmitter but cleverly leveraging the hardware you already possess. Systems get more and more integrated to reduce cost. You end up with beefy configurations when in the past you would have to buy parts by parts. At then end, your machine could have wifi on chip. Also, they are not completely off if power is provided. It's possible to have something running in low power mode, though I agree it's difficult. The upside is that if they steal your coins this way, no one is going to believe you. |
|
|
|
|
349
|
Bitcoin / Bitcoin Discussion / Re: 3 Bitcoin Doomsday Scenarios I can't find much discussion on...
|
on: November 22, 2014, 06:10:02 PM
|
|
1. The software is compromised. Worst case scenario, every node runs software that has an intentional backdoor. For example, it accepts a special signature which by passes ECDSA verification. Any coin can be transferred by using the backdoor.
Result: The blockchain is bogus - it will have to be reverted once the backdoor is detected. Massive disruption. I don't see how to undo the damages. Will have to refund a lot of people I guess.
How likely? The code is open source but not too many people review it. More over, the vast majority of the network is running the reference client in some version. So if the change was well hidden, it could happen. Similar to shellshock or heartbleed, etc.
2. Crypto is broken secretly. Like when the allies broke Enigma but never disclosed it. Very hard because several unrelated crypto algorithms are involved. They would have to be all broken for this to work (SHA, RIPEMD, ECDSA).
Result: Can steal anyone's coin but unlike 1. it cannot be easily proven. You become instantly rich.
How likely? Much much harder than 1.
3. A hidden hardware circuit transmits everything to a hidden organization.
Result: They can steal your keys because at one point or another the key has to be in memory of a computer.
How likely? Even if it's done, the sheer amount of data would make this quite impracticable. Considering how long it takes to take down terrorist cells with all the intelligence resources put to it, I doubt that anyone is capable of sifting through that much data.
One could reduce the difficulty by targeting PC Windows XP or what not, but then savvy users should be able to avoid this threat.
|
|
|
|
|
350
|
Bitcoin / Bitcoin Technical Support / Re: howto nlocktime
|
on: November 08, 2014, 01:47:05 AM
|
Edit: there's a free 0.1 BTC for the first person to discover why I was giggling like a schoolboy when I made that transaction.
Because the address sent to is 1LASS? Nope, it's slightly ruder than that. ASS? |
|
|
|
|
351
|
Bitcoin / Bitcoin Technical Support / Re: howto nlocktime
|
on: November 07, 2014, 05:45:04 PM
|
People won't hold your transaction in their memory pool for a year...
I think you misunderstand. You can't send a transaction to the p2p network until the timelock has expired. Until then you keep the transaction somewhere safe, and wait. I tested this with a transaction I made with an nLockTime 10 seconds in the future. The first time I tried to broadcast it, it was still timelocked: $ bitcoin-cli sendrawtransaction $tx
error: {"code":-26,"message":"64: non-final"}
The second time, it worked: $ bitcoin-cli sendrawtransaction $tx
8b8486d428cd5aade180437b09ce95f65ca2e9f3e3b5ea69f6ca9c47f1bd249c
Yes but that's just what bitcoind does. It won't relay non-standard tx and using nlocktime makes the tx non standard. The protocol doesn't say that. It should accept it and wait until the locktime expires before allowing mining. However, this feature could be easily abused. From main.cpp // Treat non-final transactions as non-standard to prevent a specific type
// of double-spend attack, as well as DoS attacks. (if the transaction
// can't be mined, the attacker isn't expending resources broadcasting it)
// Basically we don't want to propagate transactions that can't be included in
// the next block.
Edit: there's a free 0.1 BTC for the first person to discover why I was giggling like a schoolboy when I made that transaction.
Because the address sent to is 1LASS? |
|
|
|
|
353
|
Alternate cryptocurrencies / Altcoin Discussion / Re: How to verify ECDSA of a sample litecoin tx using pycoin?
|
on: October 30, 2014, 02:18:37 AM
|
Should work with the hash reversed Security.addProvider(new BouncyCastleProvider())
val bigR = BigInt(Hex.decode("258ad2725e66da0ae9825bb849a8e73f86e4767cf256c9fae44d18fbc1aacc2e"))
val bigS = BigInt(Hex.decode("406638a5b3369bb83d8a4f38a17b2f048c1495ebfd6fdff1a8c7b268e07f69cd"))
val pub = Hex.decode("03ec539eb3d882c07575f6143d891c18d580cd9d2726add0d71d262f2f6f2d4ccf")
val hash = Hex.decode("eed300fc63a973b668af66af746fde378ec6556f4b330ec1eeccc6a77aa535b0")
ArrayUtils.reverse(hash)
val f = KeyFactory.getInstance("ECDSA", "BC");
val ecSpec = ECNamedCurveTable.getParameterSpec("secp256k1")
val ecDomain = new ECDomainParameters(ecSpec.getCurve, ecSpec.getG, ecSpec.getN)
val signer = new ECDSASigner
val pubKey = ecSpec.getCurve().decodePoint(pub)
val params = new ECPublicKeyParameters(pubKey, ecDomain)
signer.init(false, params)
val check = signer.verifySignature(hash, bigR.bigInteger, bigS.bigInteger)
println(bigR, bigS)
println(pubKey)
println(Hex.toHexString(hash))
println(check)
(16980852742628685644910148209432903671752523748137798365042615749252787915822,29128631674996429161026020280872095602306489412358940898112602484852964420045)
(ec539eb3d882c07575f6143d891c18d580cd9d2726add0d71d262f2f6f2d4ccf,227874efbedb02b88568b55106634b9b4e3eca128ab46fa98abe7066aece0a51,1)
b035a57aa7c6cceec10e334b6f55c68e37de6f74af66af68b673a963fc00d3ee
true
|
|
|
|
|
358
|
Bitcoin / Bitcoin Discussion / Re: What full node implementation do you run?
|
on: October 27, 2014, 04:23:27 AM
|
|
I scanned a portion of the network and came out with these numbers
/Satoshi:0.9.99/: 5
/Satoshi:0.9.3/: 61
/Satoshi:0.9.2.1/: 50
/Satoshi:0.9.2/: 1
/Satoshi:0.9.1/: 36
/Satoshi:0.9.0/: 2
/Satoshi:0.8.99/: 2
/Satoshi:0.8.6/: 16
/Satoshi:0.8.5/: 13
/Satoshi:0.8.4/: 1
/Satoshi:0.8.2.2/: 2
/Satoshi:0.8.1/: 8
/btcwire:0.1.4/btcd:0.8.0/: 1
/mining.bitcoinaffiliatenetwork.com:0.9.99/: 4
Bitcoin core is #1 by far.
|
|
|
|
|
359
|
Bitcoin / Development & Technical Discussion / Re: Is it possible to add a receive address in an OP_RETURN transaction?
|
on: October 26, 2014, 02:11:42 AM
|
|
What the article means to say is that the address is a convenient display of the public key hash.
In a transaction with OP_RETURN, there is no way to redeem the coins and there is no public key at all.
That's why blockchain info display "cannot decode address".
They know how to decode two standard scripts: Pay2Pub and Pay2PubHash. The later is used more than 99% of the time.
Amaclin suggests to combine a standard p2ph output that can be decoded by bc.i and an OP_RETURN were you would store your extra info but you can't use a single outpout because it wouldn't be a standard script anymore.
Of course, it is a matter of agreement and you could push for a new type of standard script.
|
|
|
|
|
360
|
Bitcoin / Development & Technical Discussion / Re: Pay2SH - Strange transactions?
|
on: October 26, 2014, 01:55:03 AM
|
Maybe this one might is an old attempt at DDOS when the number of sig operation were not limited ? (OP_CHECKSIG do not return from the script, so every op is evaluated) ... maybe most likely a bug, I think OP_CHECKSIG consume the stack so the other one should not be able to execute. Yes, and it leaves a boolean on the stack which will be used as an arg to the next CHECKSIG. It's not a good DDOS because the script isn't redeemable and doesn't have to be checked at all. |
|
|
|
|
Show Posts
