Bitcoin Forum
June 21, 2024, 04:54:13 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 [143] 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 ... 334 »
2841  Bitcoin / Project Development / Re: 10 BTC bounty for first AT *atomic cross-chain transfer* with Script clone on: October 29, 2014, 02:44:40 PM
Did anyone express interest yet? e.g. an altcoin dev?

Yes - I have been contacted privately by a couple but no-one seems to have committed themselves to this yet - so you are welcome to join in if you are keen.
2842  Bitcoin / Development & Technical Discussion / Re: Signature Mining (to embed messages into the blockchain without using OP_RETURN) on: October 29, 2014, 02:32:43 PM
I meant it literally. The signature (r, s) is
r = kG|x
s = (H+rd)/k

[where H is the hash of the message and d the private key]
Choosing r or s means that you managed to find the matching k. It's the same problem as finding the private key. So far the best algorithm is in O(exp(n))

I am only fixing 2 bytes of the signature (so not at all a method that would work to crack a private key - just look at the timings I recorded doing the two bytes).

It is exactly the same principle that vanitygen works on (and as @cbeast hinted at using vanitygen would be a more efficient approach).

Of course it would be a very bad idea to *re-use* an address (or addresses) that were used to transmit such secrets but also understand that because the message is encrypted with a shared secret there is no way for anyone to know even which two bytes were *mined* (apart from Bob and Jane).
2843  Bitcoin / Development & Technical Discussion / Re: [BIP][Draft] BitID - "Connect with Bitcoin" protocol on: October 29, 2014, 02:30:15 PM
I had also considered this exact idea (being a fan of QR codes) - IMO the main thing to really help this to happen would be the software to be available for smart phones and a smart phone that can be *permanently disconnected from all normal comms*.

I have read about (more or less) transparent Faraday cages so I am thinking that an inexpensive approach might be to use an old smartphone and such a Faraday cage to create an authenticator that never needs to be online.
2844  Bitcoin / Development & Technical Discussion / Re: Signature Mining (to embed messages into the blockchain without using OP_RETURN) on: October 29, 2014, 02:26:22 PM
Of course another approach (used much earlier in a non-secret manner) is to use the last X decimal points to encode data (but that would generally be more costly than what I've outlined in terms of BTC).
2845  Bitcoin / Development & Technical Discussion / Re: Signature Mining (to embed messages into the blockchain without using OP_RETURN) on: October 29, 2014, 02:04:59 PM
Well - this becomes exponentially harder. If not, it would be a new attack on EC.

Sorry - I am not sure exactly what you mean but I'll take a guess...

The "difficulty" of inserting a couple of bytes remains the same per sig (just like the difficulty for creating a vanitygen address).

It is not a *competition* like normal mining is - so is more comparable to "vanity address mining" than Bitcoin mining (luck is still involved but there is no race or competition with others).

Perhaps I should not have used the term mining at all but it still requires work in much the same way as hashcash does (and I recall the word *mining* being used for vanity address creation when the idea of *safe* vanitygen address creation came into existence).
2846  Bitcoin / Bitcoin Discussion / Re: Would you work for Bitcoins? (not bitpay etc) on: October 29, 2014, 01:56:58 PM
You might find CIYAM Open interesting for this exact idea (http://ciyam.org/open) - it has already been running for nearly two years and has helped quite a few people do freelancing work for BTC (and now supports other cryptos as well).

The website "look" was designed by Enej Pungercar (who designed Bitstamp) and his contributions can be found in the list of completed tasks (as well as in the repo at https://github.com/ciyam/ciyam).

The entire system is open source so it's not in *competition* with anything else (so welcome to just study it for ideas that might help your own or even it clone it if you are technically proficient enough).
2847  Other / Beginners & Help / Re: Somebody has sent me 0.00000003 BTC on: October 29, 2014, 01:44:02 PM
Not sure if such 100-btc mistake/refund happened before, but I have read a few cases of people making mistakes in raw transactions, paying huge tx fee (a few btc), and getting refund from the mining pools.

Indeed I actually did pay (at the time) the biggest transaction fee (around 110 BTC from memory) due to doing a raw transaction after days of working 15+ hours (so a stupid mistake) and was luckily refunded at least 100 BTC of it (I forget the exact figure but it's recorded on this forum somewhere).

If the OP is worried about the silly dust amount you can do a combination of "setting your fee" and "coin-control" to "get rid of it". You can see I did this here: https://blockchain.info/tx/4fc1db306120a944324b78e4a299591a61fbc1eeed91bc5b3292d0a2420cec35
2848  Bitcoin / Development & Technical Discussion / Re: Signature Mining (to embed messages into the blockchain without using OP_RETURN) on: October 29, 2014, 10:33:43 AM
Would vanity addresses offer much?

Vanity addresses would indeed provide another way that you could "mine data" and put it into the blockchain (nice one - now we have two ways and in fact vanitygen would be a far more efficient approach).
2849  Bitcoin / Development & Technical Discussion / Signature Mining (to embed messages into the blockchain without using OP_RETURN) on: October 29, 2014, 09:56:32 AM
After having played around with OP_RETURN recently I was thinking about how it could be used for sending small encrypted messages to another Bitcoin user (much like the way Stealth addresses work). The thing that was concerning me is that OP_RETURN is "in your face" so if some authority wants to try and find your secret then they do have an obvious starting point (even if cracking the message is not feasible).

So I began to wonder - is there a simple way that such a message could be completely hidden? Then suddenly the actual ECDSA signatures jumped out at me and shouted "use us"!

I then promptly jumped into the "crypto_keys.cpp" file from CIYAM (https://github.com/ciyam/ciyam/blob/master/src/crypto_keys.cpp#L700) and made the following change:

Code:
<<  p_impl->sign_message( buf, signature );
>> for( int i = 0; i < 100000; i++ )
>> {
>>    p_impl->sign_message( buf, signature );
>>    if( signature[ 27 ] == 0xff && signature[ 63 ] == 0xff )
>>    {
>>       cout << "*** here: i = " << i << endl;
>>       break;
>>    }
>> }

I then began to record some "timing" figures and I later modified the two values from 0xff to other things and the results are here:

Code:
*** here: i = 62594 (~60 seconds)
*** here: i = 40436 (~40 seconds)
*** here: i = 4725  (~5 seconds)
*** here: i = 23288 (~20 seconds)
*** here: i = 51403 (~50 seconds)
*** here: i = 93054 (~100 seconds)
*** here: i = 19706 (~20 seconds)
*** here: i = 19298 (~20 seconds)
*** here: i = 5552 (~5 seconds)
*** here: i = 24582 (~25 seconds)
*** here: i = 16175 (~15 seconds)
*** here: i = 35453 (~35 seconds)
*** here: i = 2873 (~3 seconds)
*** here: i = 46175 (~46 seconds)
*** here: i = 27349 (~30 seconds)
*** here: i = 33235 (~30 seconds)
*** here: i = 68612 (~70 seconds)
*** here: i = 39141 (~40 seconds)
*** here: i = 2187 (~2 seconds)
*** here: i = 22733 (~20 seconds)
*** here: i = 4713 (~5 seconds)
*** here: i = 9029 (~10 seconds)
*** here: i = 8428 (~10 seconds)
*** here: i = 485 (~0 seconds)
*** here: i = 13602 (~15 seconds)
*** here: i = 1231 (~1 second)
*** here: i = 66202 (~65 seconds)
*** here: i = 28185 (~30 seconds)
*** here: i = 35853 (~35 seconds)
*** here: i = 21734 (~20 seconds)

I will note that a few times it *failed* to work (presumably this would become significantly less likely if the loop were made 10x bigger).

Code:
                                                      VV                                                                      VV
304502203c7af96966a4be769db2f6a13695c9163de188cec0672cff9e3a37f9c348e0d10221008e7f1f70d39766526f6c58f67dfc43685f005319c2b0fc1effdba84c8ccba958
3045022100c29da2a99193f7a014e343956e93fe8f056d330c770eff276e8cca7adb847f4a022016d1a3c497c06031ea52328b599f2448f39d7006fe3766edff2e9e37af47c123
304402203077ae523785fa689dd9b707c90a064240bb978e4ed737ff28a779ccb9697ead02201db68357b8b84f4e23f3a50424f91d64fbc0f05f572f1d2005ffd2fe5f2be360
3044022039460074e1c5a5770c790338ed76ef67e025c7d9748d30ff856b904f2dc3301d0220220771f7cd93d74669cde5d3c6acc75b0ef089d212b32470ecfff438f904f825
3044022031a74ec810cf2f6b767fabd5134dd136277fb530002a4bff21f7472ad26ae91702200898dce422a478b812cd257696feb78e2af40fdea2eb316d86ffafb9f1cf21d2
304502206e7b22c53c6a661daad1acdcc0b08dea256e6639c786f5ffe1ad2170d668b1b3022100bdfd93322e02ab114b0ba5b6eb2a2906cb35e97d76b4069cff9551b6aef80847
3045022025978e0a3bcc03d2f566cb035c67fe2e1a4e07addb2b8cff306761e58ef85394022100cfd649a81a82feb27015fdf5d31d79ee49a5077fe63f5b32ffa69bb109209454
304502201d49cdb57a48063743ebdcdd08c177e69610a89389e391ff36988957893e8802022100dd76901f1fa82a809067fa0bf852be86d420f258ccba21aeff8b049de39c6e6a
3046022100a4170fef1ed852fcffc5f6ead06dc494f5995145cda200eff6bc50446c5993bb022100a13168cc19bada7973bbb7e20a07836105eb653ee37a5500412113b43dbbb5ae
3045022100f81ac86878e0ae4d1efe45fae61074c047f1a89fefac00730344b7238d844bc802203215e3004435b66e64a0d0d490ee898e648f257efab09fe5006419cf05280a
304402200cdcd5e38b9ac6f6ce64af4b905a488595278595889243005a6c3b98db68bcf502200dfced0d4d93ac5079962695e26a917f125e96e577f0acf3ba001c9eea1b593f
30450220255a87cfecb578bd92fd59ed5d64922252d97fc77e4fd300784eea89e51f80760221008f1f123fcb419908dfe1ab61df1d768f2049f3bba57975fd00b6199046ed5069
3044022073c05467ba7b7494cf555b25d87fabe60e771d5bec04440017b72bf8c6f369e20220645f061baea9e64ab26296c06992d6375deab5dae3197f2e8c00d1e8208ed424
3046022100a8d9f61a674d0c2c33a315f2b39ed5aa209caf77287900713d21b71579d370f1022100e1a10e7ad5fb35a3b9a120b9d2dd4e06c82d478546249c006ae7ce571ca25899
3046022100bad3f490830c00031f0c9c48d233fd2cf0a2a380b4da0069c5e72d93c173aeda022100cf500cf504f281a74994e4d14e3b4176bfdddeae1bf53200834e4a26e7835ca4
304402204dca5e0205de87527f3a6cb441971c12375978c04172b300515f09c9544eecb10220735f77895021f228448ef40fb5a20c17979b07b29d047b206a00edf3e4ef35b2
304402200c58a2af05b52e22204aa8b665ccf0e7ac26219d518350ff71dc5a8cce3eb71002206bb7e4048c2dd758f69970a534176ed276563e5de605f3783a00d0741afa98fc
3044022052529d097530db109a2d4abf6b7153423e713f6b98e6f7ff34378a950bd534bd02202411585bd37ea0f37ac876adf4fd66e234481d610cd024d7a5008e9d7d00ba2a
304502206fd07059190a0a911fb17ad9db6c3effce9980747833c5ff6835a4777baf210e022100e9682236b9c62318df5c3a885d581df417ba917dcc254d5400f8c15e528a1ca2
3045022100fadb120ee656e5b15d1f627d16cf22342a029fcf3580ff2d0f3b6a7f6ffd2bd6022058ab8f851fd27694476a3cf9efcd86511baee8342231861b00f0c9ef12def41e
30450220157dada2594d8deeb796a1febc22a4d6f37d9ae70cf474008b41261d7804872a022100c3f1b2caa33f7630a99e5eeaccf54a2b71d0a16b2384e2dafff81b7e25b9ce97
3045022016ed0e589674cd6da54bbadda751199a1a3b8b7907df2500d46b0719ba5c2db9022100b018f3416d3ae4116b50e18e6c0204e8574fcf03fc56694dff6ea776bc0f3259
304402205c4e5588d8eec6fec579e0f312d0528f4312a89c34862e007466f89e21fdd5600220469273b123361889281595ea4ed50b9340ed5fd0613de2f30eff774874225b76
304502207349da2efe4de858e2cb0aef7cfd06cf0027ad2b5e47b70021a3b3bf885bfeea022100876d52c01fcfbe9cba9f315ffad529f047428f0482c9b535ff5372d487ef3bf2
3045022030c0efecadc6e5e8c09c86ca8084df1711817882cf4d28018faf98d578e84a5d0221008d65c4af49e1de65bdb5bbc5453ddc107b913ece9012712402e3902be4da47e5
30440220085ac17ad265c0a40891f357cd9a323d94743b20f100d30330ae331d086ba2490220402f9a53c8b3e087c61f9df8efe0c78b4e95f1dcc3e2c5757104af9eac0380f2
3045022100dd063e119149e1b902a2d4cad08e823f018bdb175a8105cbf158cbefd9659f80022022564ba20b5fd65780a14bfb34a665e20c20f979bc4fb06e06e378d2d2225acf
3045022100eaf76c3f2f94a9f9e66ddad40ab36721a09a670dffc907390d01b8c87170cf7d02202189be2ee195869d4a7fac206b5624787c7a1b03e58b8903084ae6986a207f9c
3046022100d028bd2d3587abbed253615da8e67bb8d9006c4b2baa138d688b1a3a0d296274022100c55309b7de2af7a8d96f266892718d89792369fd23fe1737f8833eda31a9b1aa
3045022100dec32fe7b0a2e7fa407cdf2a6bb1bc3675fcb1ff39ce1360526093cde12172e0022033aab7cc7e3b42a24813f68a1495b331e3b9ac4ffa2fcb413778b1600d7f055e
                                                      ^^                                                                      ^^

If you look carefully at the column of bytes I have put the VV and ^^ markers on you'll see that I am *in control* of those bytes that are part of the ECDSA signature (because of the looping).

What am I actually doing?

I am *mining* the signature in order to store information in it (possible because of the *random* k value that is used when creating such signatures).

How could this be useful?

Imagine Bob wishes to send his friend Jane a private small message. Firstly he would send a normal Bitcoin transaction to Jane (exposing the public key of a UTXO he owns) and then Jane would send a transaction back (exposing her public key). Using ECDSA it is now possible for Bob and Jane to create a "shared secret" (same as is done for Stealth Addresses).

After this Bob would ask Jane for a new address and then Bob would encrypt his message with the "shared secret" and embed it into a set of UTXOs within the actual ECDSA signatures which would be sent to Jane as a normal Bitcoin transaction (nothing to make it stand out like OP_RETURN at all).

Jane knowing that this came from Bob and it has been sent to the address she gave him to send the secret message to can now use her "shared secret" to extract this message.

My initial tests suggest that on average hardware a small message (say 50 characters) might take an hour or so to "mine" (althugh I made no attempt to optimise anything).

Is this useful?

I think it could be of some use in at least providing another way that small amounts of data can be stored in the blockchain without it being at all *obvious* that such data is actually there.

Enjoy!
2850  Bitcoin / Bitcoin Discussion / Re: Why blockchains might want to consider using AT "Turing complete" txs on: October 29, 2014, 06:07:27 AM
While I am thinking about "higher level" languages ideally what I'd like to do is to have GCC able to compile code based on the AT instruction set so if there are any GCC gurus (i.e. people that know how to add a new instruction set for it to work with) who are interested in AT then please get in touch.
2851  Bitcoin / Bitcoin Discussion / Re: Why blockchains might want to consider using AT "Turing complete" txs on: October 29, 2014, 01:09:38 AM
Kind of annoying that this has every instruction taking memory operands directly, instead of a load/store architecture like Moxie.  This makes it much harder to write a secure virtual machine, since you need to make sure there are boundary checking in many places instead of just two.

I'm not quite sure about the issue you've raised here - we have already written all the boundary checks and completed all the unit tests to prove that they work (it is basically just *one* function that each op code which needs to check if a memory location is valid calls and it could easily be *inlined* for better performance).

Actual AT machine code doesn't need to do any such checks as the machine will simply gracefully fail if they attempt to read or write outside of their valid memory range.

The design choices made were primarily about keeping the *code size* of the ATs as small as possible (thus only the SET_VAL op code takes a 64 bit literal value and most other op codes take one or two 32 bit addresses) and preventing anything such as "self-modifying code" or invalid branching.

Also I am neither a fan of the JVM nor Java (and haven't written any code in Java since the 1990s) so it is perhaps unsurprising I had not even heard of the Moxie project that you mention before I read your post.

Anyway - if Moxie is suitable for blockchain usage then of course people should decide which VM is the best fit for their blockchain (we are not claiming AT is *the best VM* but simply that it is *available* and that we have already built an atomic cross-chain transfer program for it so it should be quite useful even as is and without a higher level language).

In regards to "dead code" it is envisioned that ATs with no UTXOs left could be removed as part of pruning.

As far as performance goes only testing will reveal how useful an addition AT is (note that limits are recommended to prevent AT from ever becoming too big a burden for peers to handle).
2852  Bitcoin / Project Development / Re: 10 BTC bounty for first AT *atomic cross-chain transfer* with Script clone on: October 28, 2014, 03:56:16 PM
And this is being implemented in Quora?

The Qora implementation will be happening very soon.

We might first prove the atomic use case just using some testnets though.
2853  Bitcoin / Project Development / Re: 10 BTC bounty for first AT *atomic cross-chain transfer* with Script clone on: October 28, 2014, 03:40:38 PM
I thought AT you were abbreviating Atomic transactions. Can you please send me a link?

You can see the entire docco from here: http://ciyam.org/at

and for the "atomic" use case in particular here: http://ciyam.org/at/at_atomic.html
2854  Bitcoin / Project Development / Re: 10 BTC bounty for first AT *atomic cross-chain transfer* with Script clone on: October 28, 2014, 03:32:29 PM
malleability applies to any transaction, not just multisig. Because the miners can just slightly alter the tx without invalidating the script.

You don't understand AT at all - it is not a Bitcoin script.

Please re-read TierNolan's post and review the AT use case and then *think again*.

All you can do with *malleability* is *change the sig* and that doesn't affect AT (as the atomic use case does not depend upon that at all).

For that to be an issue you'd need AT to *care about the sig* and *it simply doesn't* (the refund address is hard-coded and is not dependent upon the tx sig at all).

Fundamentally TierNolan's approach requires B to sign A's *refund* (and vice-versa) but AT's approach *does not* (so although the atomic AT was *based* upon TierNolan's idea it is not the same as it).
2855  Bitcoin / Project Development / Re: 10 BTC bounty for first AT *atomic cross-chain transfer* with Script clone on: October 28, 2014, 03:18:03 PM
How is malleability not an issue? TX2 is a refund of TX1... thus TX2 spends the hash of the raw TX1 (The TXID). That txid in TX1 can be changed by the miners thus invalidating the refund holding the funds permanently hostage. So TX2 is invalidated and the counterparty doesnt sign again. The funds are permanently stuck. If this is somehow not the case, can you please explain why? I'm familiar with atomic trades and always assumed that was their issue (unilateral hostage commitment)

The TierNolan approach uses a multi-sig address (which is what the malleability issues he describes are all about).

The AT solution does not need or use this (there is *no* multisig address involved at all). You might want to read the AT use case more carefully to understand it.
2856  Bitcoin / Project Development / Re: 10 BTC bounty for first AT *atomic cross-chain transfer* with Script clone on: October 28, 2014, 02:30:59 PM
Just to make things clear "atomic" does not imply ACID (http://en.wikipedia.org/wiki/ACID) as that *word* it is only *one part of the normal idea for RDMBS txs" (there are *four* words in the acronym for a reason).

The AT "atomic" transfer does satisfy the "atomic" requirement that a transfer should be *all or nothing* but of course this is a blockchain environment not a single server so some "edge cases" (clearly described in http://ciyam.org/at/at_atomic.html) do exist.

Transaction *malleability* (as mentioned by TierNolan) is not an issue when using AT as it doesn't not have "multisig addresses" but of course if the creator of the first AT sends the tx with the "secret" to the other chain and then "loses all connectivity to the internet for the timeout period" then they will end up losing their funds (same thing could happen with any other method of transfer if you don't decide to use a "trusted server").

This is the same problem that TierNolan's script would have also and compared to the problem of an *exchange collapsing* is IMO not an issue (provided the timeouts for refunds are sensible - say 24 and 12 hours per TierNolan's suggestion).

People demanding "perfection" should for a start realise that no PC is *perfect* and that the *internet is not perfect either* (both of these facts are very obvious when you use a cheap Chinese laptop from within China as my PC often crashes for no good reason and the internet here is always being blocked).
2857  Bitcoin / Project Development / Re: 10 BTC bounty for first AT *atomic cross-chain transfer* with Script clone on: October 28, 2014, 08:33:42 AM
Great to see that the AT completed (next step is of course testing).

I have now uploaded the atomic use case http://ciyam.org/at/at_atomic.html.
2858  Bitcoin / Project Development / Re: 10 BTC bounty for first AT *atomic cross-chain transfer* with Script clone on: October 27, 2014, 02:03:09 AM
You can do atomic trade with regular old bitcoin script. Would that qualify for this bounty?

The bounty is clearly for using an atomic cross-chain transfer *AT* to perform this between Qora and a Bitcoin clone.

And btw the atomic cross-chain transfer AT is actually *based* upon TierNolan's work (so I am of course well aware of its existence).
2859  Bitcoin / Bitcoin Discussion / Shamir's Secret Sharing algo in C/C++ under MIT license? on: October 25, 2014, 02:30:29 PM
Just wondering if anyone has source code that is not GNU licensed for this (as much as I respect the point of GNU it's licensing is not suitable to my project).

I already have the GNU licensed ssss package (so need to give me that link) but I would prefer something MIT licensed that I can use in my own project.
2860  Bitcoin / Bitcoin Discussion / Re: A difference of opinions at the Bitcoin Foundation regarding the XBT proposal? on: October 25, 2014, 01:31:02 PM
This seems like a *storm in a teacup* to me.

No-one is asking anyone to change the way that their preferred Wallet displays things - the idea of an XBT code is just for *standards compliance* so whatever is *normal practice* is of course what should be used for that (do most people concern themselves with XAU when talking about gold?).
Pages: « 1 ... 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 [143] 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 ... 334 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!