Latest posts of: coinlatte

Show Posts
Pages: [1] 2 »

Bitcoin / Development & Technical Discussion / Re: Wallet Label Export Format: A Proposal by Craig Raw

on: August 27, 2022, 08:51:08 AM

Quote

Descriptors are great but they're not human-readable, which is probably why the BIP doesn't make use of them.

What is not readable?

Code:

importdescriptors "[{\"desc\":\"addr(1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg)#d5ts4kht\",\"timestamp\":\"now\",\"label\":\"Withdraw address for Binance account\"}]"

Also note that in Bitcoin Core, there is "Export" button, and you can get CSV file in your output, so the whole format for that is already established:

Code:

"Confirmed","Date","Type","Label","Address","Amount (BTC)","ID"
"true","2015-02-14T13:26:20.000","Sent to","Withdraw from Binance at 01-01-2021","1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg","-21.61679877","c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎"

However, importing labels for transactions is not implemented. You can change them, if you set them for addresses.

Bitcoin / Development & Technical Discussion / Re: Wallet Label Export Format: A Proposal by Craig Raw

on: August 25, 2022, 05:16:37 PM

So far, I used the most portable format I can think of: the command-line-based format: Code: importdescriptors "[{\"desc\":\"tr(cMahea7zqjxrtgAbB7LSGbcQUr1uX1ojuat9jZodMN87JcbXMTcA)#tnrke5yz\",\"timestamp\":\"now\",\"label\":\"taproot\"}]" importdescriptors "[{\"desc\":\"tr(cMahea7zqjxrtgAbB7LSGbcQUr1uX1ojuat9jZodMN87K7XCyj5v)#xpd75frm\",\"timestamp\":\"now\",\"label\":\"taproot2\"}]" It is standardized across wallets, it is extensible, and it is reasonably-compatible between different versions of Bitcoin Core. Also, in case of incompatibility, it is quite easy to fix it, and convert into another version of Bitcoin Core.

Bitcoin / Development & Technical Discussion / Re: Intentionally make a transaction slower

on: May 02, 2022, 07:04:04 PM

Quote For now, it is locked, just to stick to the topic and make it really slow. But you can reply with your multisig, then I could make it faster, to form a complete example. I think vjudeu waited long enough, here you are: 495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf40. As everyone can see, vjudeu's signature is exactly the same, that means I could just copy-pasted it, without asking for re-signing.

Bitcoin / Development & Technical Discussion / Multisig based on public key hashes instead of public keys

on: April 28, 2022, 07:39:57 PM

Is it possible? And if so, why don't we use public key hashes instead of public keys? For example, let's assume we have first two private keys:

Code:

alicePrivKey=0000000000000000000000000000000000000000000000000000000000000001
bobPrivKey=0000000000000000000000000000000000000000000000000000000000000002

Then, each party can compute its public key:

Code:

alicePubKey=0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
bobPubKey=02c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5

And then, each party can compute its address:

Code:

aliceAddress=bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
bobAddress=bc1qq6hag67dl53wl99vzg42z8eyzfz2xlkvxechjp

Sending to address is enough to get it recorded on-chain. If coins were never moved, then it is impossible to know the public key. But it may be possible to create a multisig that is based on such address. For example, we can start from getting hashes for each of them:

Code:

aliceHash=751e76e8199196d454941c45d1b3a323f1433bd6
bobHash=06afd46bcdfd22ef94ac122aa11f241244a37ecc

And then, we can create 1-of-2 multisig, when revealing only one public key is needed to move the coins:

Code:

OP_DUP OP_HASH160 OP_DUP 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUAL OP_SWAP 06afd46bcdfd22ef94ac122aa11f241244a37ecc OP_EQUAL OP_ADD OP_VERIFY OP_CHECKSIG

As far as I know, it should work in theory, but I still cannot confirm it would work in practice. Both paths should be spendable. For Alice, it would be:

Code:

<sigAlice> <pubkeyAlice>
<sigAlice> <pubkeyAlice> <pubkeyAlice>
<sigAlice> <pubkeyAlice> <hashAlice>
<sigAlice> <pubkeyAlice> <hashAlice> <hashAlice>
<sigAlice> <pubkeyAlice> <hashAlice> <hashAlice> 751e76e8199196d454941c45d1b3a323f1433bd6
<sigAlice> <pubkeyAlice> <hashAlice> 1
<sigAlice> <pubkeyAlice> 1 <hashAlice>
<sigAlice> <pubkeyAlice> 1 <hashAlice> 06afd46bcdfd22ef94ac122aa11f241244a37ecc
<sigAlice> <pubkeyAlice> 1 0
<sigAlice> <pubkeyAlice> 1
<sigAlice> <pubkeyAlice>
1

And for Bob, it should left "0 1" instead of "1 0" on the stack, so after addition, OP_VERIFY will succeed by consuming OP_TRUE. I am still trying to confirm that on regtest, but I think it should be technically possible to use public key hashes to make a multisig, instead of using public keys.

Bitcoin / Development & Technical Discussion / Re: Importing taproot keys

on: November 24, 2021, 06:25:00 PM

Quote

You can read the details of it in this section: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#constructing-and-spending-taproot-outputs

How exactly keys are tweaked? Because every time I am getting wrong results, one correct example could be helpful. For example I have something like this:

Code:

internal_key=0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
tweak*G=0379A78517D39A73C6268BA907022D2B1144412988BD6BD059C0FB032FBBCC66C8
tweaked_key=02DA4710964F7852695DE2DA025290E24AF6D8C281DE5A0B902B7135FD9FD74D21
tweaked_key=internal_key+tweak*G
SHA-256("TapTweak")=e80fe1639c9ca050e3af1b39c143c63e429cbceb15d940fbb5c5a1f4af57c5e9
bytes(internal_key)=79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
SHA-256(SHA-256("TapTweak")||SHA-256("TapTweak")||bytes(internal_key))=SHA-256(e80fe1639c9ca050e3af1b39c143c63e429cbceb15d940fbb5c5a1f4af57c5e9e80fe1639c9ca050e3af1b39c143c63e429cbceb15d940fbb5c5a1f4af57c5e979BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798)=3cf5216d476a5e637bf0da674e50ddf55c403270dd36494dfcca438132fa30e7
3cf5216d476a5e637bf0da674e50ddf55c403270dd36494dfcca438132fa30e7*G=02CC2A7558AE6D55AA13FDD0A7F1E77A5C212970EC5A571652E35D7B6A3F7A415D
02CC2A7558AE6D55AA13FDD0A7F1E77A5C212970EC5A571652E35D7B6A3F7A415D!=02DA4710964F7852695DE2DA025290E24AF6D8C281DE5A0B902B7135FD9FD74D21 (failed)

Other / Off-topic / Re: What happens in a copyright infringement scenario?

on: November 21, 2021, 01:29:03 PM

Quote You could only achieve this on a shit chain such as BSV's, as the blocks can't weight more than 4MBs in Bitcoin. It depends how long you want to wait and how much you are willing to pay. With empty mempool, 4 MB per 10 minutes is quite slow transfer, so to push 4 GB video, it would take at least 1000 blocks, so about a week. Also, assuming one satoshi per stored byte, it would cost 0.01 BTC per megabyte, so around 40 BTC for storing that with the lowest fees. Also note that you can upload any data in a hidden way. For example, you can use some HD wallet to generate pseudorandom keys, then you can tweak them with 32-byte chunks from your video file. When all coins will be moved back to your wallet and you will have a lot of confirmations, then you can release your xprv and release some program that will extract that data. Another thing is you don't have to actually pay that 40 BTC to do that. If you are some big exchange with some significant liquidity, then you move a lot of coins in your daily transactions, so all that you need is tweaking keys with chunks of data you want to store. Also if you can produce deterministic signatures, then you can tweak them too. So the true cost is not really 40 BTC, but rather 4 GB / 32 byte keys = around 2^27 keys. If you assume each output has one public key and one signature, it would mean the total cost is spending 2^26 outputs. So if you have that much traffic with random keys, you can upload videos for free, just by switching to deterministic keys and signatures, and tweaking them with your data.

Bitcoin / Development & Technical Discussion / Importing taproot keys

on: November 21, 2021, 02:32:40 AM

I tried the latest official 22.0 version. Now I know that importing taproot keys by WIF is possible, but I am getting strange results, it seems the keys are completely different than I am trying to import.

Code:

importdescriptors "[{\"desc\":\"tr(cMahea7zqjxrtgAbB7LSGbcQUr1uX1ojuat9jZodMN87JcbXMTcA)#tnrke5yz\",\"timestamp\":\"now\",\"label\":\"taproot\"}]"
importdescriptors "[{\"desc\":\"tr(cMahea7zqjxrtgAbB7LSGbcQUr1uX1ojuat9jZodMN87K7XCyj5v)#xpd75frm\",\"timestamp\":\"now\",\"label\":\"taproot2\"}]"

What was imported:

Code:

bcrt1pmfr3p9j00pfxjh0zmgp99y8zftmd3s5pmedqhyptwy6lm87hf5ssm803es
bcrt1pet7ep3czdu9k4wvdlz2fp5p8x2yp7t6ttyqg2c6cmh0lgeuu9laspse7la

What I expected:

Code:

bcrt1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqc8gma6
bcrt1pccz8l9zpa47k6vz9gphftsrumpw80rjt3nhnefat4symjhrsnmjsgkm3r6

Why my public keys from taproot addresses are not the same as in my WIF's? Also I wonder why if I want to sign my transactions offline with Bitcoin Core I have to import my keys to regtest/testnet/signet instead of mainnet if my client does not have the chain?

Bitcoin / Development & Technical Discussion / Representing fractional satoshis in difficulty-like format

on: April 12, 2021, 01:35:45 PM

For now, we have 64-bit numbers for representing amounts. We have satoshis as the smallest units and we have maximum coin supply of 21 million coins. That means we need at most 51 bits to represent any amount now. In the future, sooner or later, introducing fractional satoshis would be needed. The easiest way to expand it further when we use all 64 bits is just expanding it to 128-bit or even 256-bit number, but it seems unnecessary. We already have 256-bit targets expressed as 32-bit numbers when we deal with difficulty. The same method can be used to introduce fractional satoshis: one byte could be used to allow going up to 256 times smaller amounts than now, and the rest could be used to express the shifted value. Some examples: Code: 21 million coins: 000775f05a074000 one satoshi: 0000000000000001 one millisatoshi: 0a00000000000001 one microsatoshi: 1400000000000001 one nanosatoshi: 1e00000000000001 one picosatoshi: 2800000000000001 one femtosatoshi: 3200000000000001 one attosatoshi: 3c00000000000001 That also means that it will be impossible to express some amounts, but it is by design, just to avoid paying 0.000000001234567890123456789012345678901234567890 BTC in single output. I think that 56 bits should be sufficient to express any amount precisely enough, and the first 8 bits just allow to shift them to the right and express smaller amounts in this way.

Bitcoin / Development & Technical Discussion / Re: Is this HD wallet secure?

on: March 06, 2021, 02:02:33 PM

It is just "firstAddedValue" multiplied by base point G. Edit: some more complex example: path: "0/SHA-256('bitcointalk.org')/5321992/SHA-256('coinlatte')" masterPrivateKey: `1c4f3bbd6703e3eb65040b37669046da93009b024aad0cef1b3cc57157e388ec` masterPublicKey: `02 a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd` firstAddedData: `a34b99f2 2c790c4e 36b2b3c2 c35a36db 06226e41 c692fc82 b8b56ac1 c540c5bd 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000` masterPrivateKey: `1c4f3bbd6703e3eb65040b37669046da93009b024aad0cef1b3cc57157e388ec` firstAddedValue: `db26845476a175bd67c1e2b96812ea4aaa772f401fd23edabb98155e53d6b612` firstPrivateKey: `f775c011dda559a8ccc5edf0cea331253d77ca426a7f4bc9d6d4dacfabba3efe` masterPublicKey: `02 a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd` firstAddedPoint: `02 b87ef5ad03264ef973f7f1a710397f2aa365dd7c48514550aee83ac9c2cb4183` firstDerivedKey: `02 1dbe25ac1b430b911bda0f22d11c65a6e0fcc4861ac2a56ae8e8db27fd82ebd5` SHA-256("bitcointalk.org"): `f245bd5620ee79314f48d9e9641a5406bd03745f6ac516e2801ef6ccbfe40ced` secondAddedData: `1dbe25ac 1b430b91 1bda0f22 d11c65a6 e0fcc486 1ac2a56a e8e8db27 fd82ebd5 f245bd56 20ee7931 4f48d9e9 641a5406 bd03745f 6ac516e2 801ef6cc bfe40ced` firstPrivateKey: `f775c011dda559a8ccc5edf0cea331253d77ca426a7f4bc9d6d4dacfabba3efe` secondAddedValue: `96c14d3fdf2e9864881489162888d20822e9a8737d922975d2846566fc7efa0c` secondPrivateKeyNegative: `8e370d51bcd3f20d54da7706f72c032ea5b295cf38c8d503e986e1a9d802f7c9` secondPrivateKey: `71c8f2ae432c0df2ab2588f908d3fcd014fc4717767fcb37d64b7ce2f8334978` firstDerivedKey: `02 1dbe25ac1b430b911bda0f22d11c65a6e0fcc4861ac2a56ae8e8db27fd82ebd5` secondAddedPoint: `02 258b3ca9f770ef770667979d25619331ced43781f0b5e910fca03048631e7fdd` secondPublicKey: `03 3bd31277f4501c0a3ec6cba83d320f2991060ca6b9709e256537d221b33f499a` secondDerivedKey: `02 3bd31277f4501c0a3ec6cba83d320f2991060ca6b9709e256537d221b33f499a` hexNonce(5321992): `0000000000000000000000000000000000000000000000000000000000513508` thirdAddedData: `3bd31277 f4501c0a 3ec6cba8 3d320f29 91060ca6 b9709e25 6537d221 b33f499a 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00513508` secondPrivateKey: `71c8f2ae432c0df2ab2588f908d3fcd014fc4717767fcb37d64b7ce2f8334978` thirdAddedValue: `c18d4399f29d74188d9abb1224b419898a41396426b34bf1d1f74e70284c0dba` thirdPrivateKey: `3356364835c9820b38c0440b2d88165ae48ea394edea76ede8706cc6504915f1` secondDerivedKey: `02 3bd31277f4501c0a3ec6cba83d320f2991060ca6b9709e256537d221b33f499a` thirdAddedPoint: `03 431bb4ae33a5ca7fc2f0394b09d2c6882ae6077eb861e3cb8c4be700a0ff8f71` thirdDerivedKey: `02 099f41117ea008c165847e75483d34384a9f36c2afe81176f38e58c512d2a70e` SHA-256("coinlatte"): `314870494d3a9136ba0a67ceb33534cbd438e982105d20cc076204c6fc99594d` fourthAddedData: `099f4111 7ea008c1 65847e75 483d3438 4a9f36c2 afe81176 f38e58c5 12d2a70e 31487049 4d3a9136 ba0a67ce b33534cb d438e982 105d20cc 076204c6 fc99594d` thirdPrivateKey: `3356364835c9820b38c0440b2d88165ae48ea394edea76ede8706cc6504915f1` fourthAddedValue: `a1cd9ea8dc605f136011a8e597329edb259e6758aec9f8772e1ae84780d62679` fourthPrivateKeyNegative: `d523d4f11229e11e98d1ecf0c4bab5360a2d0aed9cb46f65168b550dd11f3c6a` fourthPrivateKey: `2adc2b0eedd61ee1672e130f3b454ac8b081d1f9129430d6a947097eff1704d7` thirdDerivedKey: `02 099f41117ea008c165847e75483d34384a9f36c2afe81176f38e58c512d2a70e` fourthAddedPoint: `02 fc6cc7b860bfb2612aca72cca75892e9601457c41641c3fc54741e16a13999d1` fourthPublicKey: `03 4467102eac1316de0875b25c9990bb8ad61aa8860e4a42f74ff11734a0fb6ed6` fourthDerivedKey: `02 4467102eac1316de0875b25c9990bb8ad61aa8860e4a42f74ff11734a0fb6ed6` So, if I calculated everything correctly, then for "masterPrivateKey" of `1c4f3bbd6703e3eb65040b37669046da93009b024aad0cef1b3cc57157e388ec` and with "0/SHA-256('bitcointalk.org')/5321992/SHA-256('coinlatte')" path, we should get `02 4467102eac1316de0875b25c9990bb8ad61aa8860e4a42f74ff11734a0fb6ed6` public key and `2adc2b0eedd61ee1672e130f3b454ac8b081d1f9129430d6a947097eff1704d7` private key.

Bitcoin / Development & Technical Discussion / Re: Is this HD wallet secure?

on: March 06, 2021, 01:24:41 PM

Code: $ hexdump -Cv key.bin 00000000 a3 4b 99 f2 2c 79 0c 4e 36 b2 b3 c2 c3 5a 36 db \|.K..,y.N6....Z6.\| 00000010 06 22 6e 41 c6 92 fc 82 b8 b5 6a c1 c5 40 c5 bd \|."nA......j..@..\| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \|................\| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \|................\| 00000040 $ sha256sum key.bin db26845476a175bd67c1e2b96812ea4aaa772f401fd23edabb98155e53d6b612 key.bin Then, ECDSA operations needs to be done here: firstAddedValue: `db26845476a175bd67c1e2b96812ea4aaa772f401fd23edabb98155e53d6b612` firstAddedPoint: `02 b87ef5ad03264ef973f7f1a710397f2aa365dd7c48514550aee83ac9c2cb4183` masterPublicKey: `02 a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd` firstDerivedKey: `02 1dbe25ac1b430b911bda0f22d11c65a6e0fcc4861ac2a56ae8e8db27fd82ebd5` So, "firstDerivedKey" is just ECDSA sum of points "masterPublicKey" and "firstAddedPoint". It starts with "02", then fine, we have it. If it would start with "03", then we would negate it and get point with identical X value, just with reversed Y value.

Bitcoin / Development & Technical Discussion / Re: Is this HD wallet secure?

on: March 06, 2021, 12:08:17 PM

Quote If I am understanding you correctly, you are taking the master public key (I'll just call it M) and a nonce N, and concatenate them together like this: [M N] That is correct. Quote and hashing it all with SHA256 to get the child key? Hashing is used just to get a number that is then added to this master public key. I could just increment my master public key, but then everyone would be able to link all of those addresses together, so that is why hashing is used, to get some deterministic offset from this master public key. Quote First it is trivial to derive the child key several numbers apart, so that the security of all of the keys depends on how well you safeguard the master private key. If you have master public key, then it is trivial to derive other public keys that are deeper in the tree. But finding private keys is impossible (as far as I know), because you only know that master public key and the offset from this key if you know the nonce. Also, going to previous public keys in the tree seems to be impossible. Quote By contrast, a BIP32 HD wallet has several different layers of "nonces" (paths actually) so it would be slightly harder to find some child key if the master private key was compromised, assuming you used a non-standard derivation path. In my scheme, you always just derive child keys from public keys, it is possible to create any path you want. So, you can just have one master public key and increment your nonce, but you can also do it in a different way and create paths like "15/32/5/7". Just take 15th (starting from zero) public key, derive 32th public key from it, then 5th key from this key and finally the 7th key from this key. Quote You can mitigate this by using a random 256-bit nonce Nonce cannot be random, because the whole wallet have to be deterministic. You need to get nonce somehow, you can use a hash of something as a nonce, but then you need that data. So, for example if you use a hash of username, you have to know that username to derive keys properly. But if you use hash of some data as a nonce, you have to make sure that this data is unique (usernames have to be unique). Quote or even ditch it all together and just SHA256 M to get the first key, SHA256 it again to get the next one and so on Getting any key should be as fast as possible. So, if some user has 1,000,000 th key, it should not be forced to calculate SHA-256 1,000,000 times, just once. Quote And second, the message length of SHA256 is 512 bits, this means that SHA256 actually hashes blocks of 512 bits at once - but of course spits out a 256-bit result - so if you just start from "0" and someone breaks a couple rounds of SHA256 for one of these inputs, then theoretically that can be used to break those rounds for all other [M N] combinations with different nonces as well, and that's because if an input isn't a multiple of 512 bits it's extended by a one bit followed by a bunch of zero bits to extend it to a multiple of 512. So from SHA256's point of view, the first couple child keys are dangerously close to M with no nonce at all! Why? Any hashed message is always 512-bits aligned, you have 256-bit public key and 256-bit nonce. Then, the second block in SHA-256 always looks like this: `80000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000200` But as you don't know the offset of the master public key if you received only derived public key, you have no idea what SHA-256 output you should start with when trying to reverse it.

Bitcoin / Development & Technical Discussion / Is this HD wallet secure?

on: March 06, 2021, 08:39:46 AM

I know about BIP 32, but I tried to do things in a simpler way and wonder if such design is secure enough. First, we start with some master key, in this example we use output from executing SHA-256 on empty string, in real application it would be generated randomly in any secure way, for example as it is done by OpenSSL. Because if we use it directly, we would have some public key starting with "03" prefix, so we negate the result to get all public keys starting with "02", so we can make them all 256-bit. The same we can do for every public key if we ever get "03" prefix. sha256empty: `e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855` masterPrivateKey: `1c4f3bbd6703e3eb65040b37669046da93009b024aad0cef1b3cc57157e388ec` masterPublicKey: `02 a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd` Then, if we want to get some keys from this master public key, we simply need to add some known number to it. To generate such number, we combine this 256-bit public key with 256-bit nonce and execute SHA-256 on it. firstHashedData: `a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd 0000000000000000000000000000000000000000000000000000000000000000` firstAddedValue: `db26845476a175bd67c1e2b96812ea4aaa772f401fd23edabb98155e53d6b612` firstPrivateKey: `f775c011dda559a8ccc5edf0cea331253d77ca426a7f4bc9d6d4dacfabba3efe` firstDerivedKey: `02 1dbe25ac1b430b911bda0f22d11c65a6e0fcc4861ac2a56ae8e8db27fd82ebd5` secondHashedData: `a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd 0000000000000000000000000000000000000000000000000000000000000001` secondAddedValue: `6dbcfbb893a11df2abbcf8997c10da5dcf8d14a19eca8510002188bce19d7ee4` secondPrivateKey: `8a0c3775faa501de10c103d0e2a12138628dafa3e97791ff1b5e4e2e398107d0` secondDerivedKey: `02 7367ad233c2e83f265a4751219e5ff3c4d3719e0d6f3e37147ecb011441e1749` To make it more convenient, instead of incrementing nonce, we could also place some hash of SHA-256 here, for example if we have unique usernames, we could take the hash of this username (or hash of any other meaningful data). Thoughts?

Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][2POW] Luck - A new consensus algorithm to eliminate large mining pools

on: January 17, 2021, 05:21:50 PM

Now it works, but as I have less than 1 TB, I didn't mine any block so far.

Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][2POW] Luck - A new consensus algorithm to eliminate large mining pools

on: January 15, 2021, 07:44:43 AM

Now, plotting function returns true, but there are no files in the plotting directory. Also, is it possible to connect through Tor? I am guessing that if I am not connected, plotting will not start. I can see zero peers in console messages, so I am guessing that is the root of my problems.

Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][2POW] Luck - A new consensus algorithm to eliminate large mining pools

on: January 14, 2021, 08:49:18 AM

How to run miner.startPlot command? Could you give some working example? It seems that the last two arguments have to be strings and I don't know how should I type them, as this method returns false for everything I tried so far.

Bitcoin / Development & Technical Discussion / Re: bitcoin-cli cold sign raw transaction

on: January 06, 2021, 05:30:42 PM

Quote It would also be helpful if you decode your transaction hex into JSON and post it here, erasing parts like addresses which you don't want to show if any. I suspect you could be having the same symptoms as the other thread, the vins having an empty ScriptSig. More than that: you can run your client with regtest mode and then reproduce it with worthless regtest coins and paste results here. You can use one client as a miner, create some blocks and then use another instance of a regtest client pointed to different directory and different port, then try to sign a transaction from the second client. If both clients are disconnected from each other, it should be enough to reproduce it.

Bitcoin / Development & Technical Discussion / Re: Is there any research on different key-value DBs suitable for bitcoin?

on: December 28, 2020, 07:09:37 PM

Quote Obviously any change in the database used for wallet.dats will be rejected since it will break compatibility with all tools that depend on the structure. The only thing that users need is the "xprv" value if it is HD wallet or all WIF-encoded private keys if it is not. By having private keys it is possible to recover everything else. Am I missing something? Both things can be easily written on a piece of paper and expressed in text as needed, so they are as "standard" as they could be.

Bitcoin / Development & Technical Discussion / Sending old blocks as compressed by default

on: December 26, 2020, 10:35:42 PM

Now, all blocks are sent in uncompressed form. They can be compressed by each node on their own, there are many ways of shrinking that data that could always be made losslessly, for example nonce can always be placed as four bytes in previous block hash instead of zeroes (because there always will be zeroes, 32 zero bits are mandatory). Many things are repeated in the blockchain, so if we create some new nodes, they have to download everything and validate uncompressed data. As validation take some time anyway and sometimes storage or network bandwidth is limited, maybe it is a good idea to send old blocks in compressed form, for example by making such "compressed block dump" every 210,000 blocks. In some edge cases where halving is nearby, we can wait 2 weeks before we compress blocks from last halving, just to make sure we are safe from reorgs just before or just after halving.

Bitcoin / Development & Technical Discussion / Re: Calculate z and z1 from ECDSA Signature

on: May 08, 2020, 08:32:19 AM

I guess that z and z' has the same meaning as in this Wikipedia article. If so, then z is simplified transaction hash. All you need to do is just calculate SHA-256(simplified_transaction) and that will be your z. The same for z', it will be just another simplified transaction signed using the same k value. Here you have two inputs, so for each of them you should create two different simplified transactions. Here is some example.

Bitcoin / Development & Technical Discussion / Re: Lightning Network over mempool using Replace By Fee

on: February 19, 2020, 01:24:24 PM

Quote Imagine tens of thousands of such or longer chains in the mempool. Who's going to have enough memory to store all of them to ensure that none of them is dropped? It is possible right now. You can send any transaction using 1 satoshi per byte fee and no one will stop you from spamming the network with such transactions right now. Sooner or later, mempool will reach maximum capacity and then we should have some kind of mechanism to decrease this load. If we have RBF transactions in such overloaded mempool, we can provably replace two or more transactions with one equivalent transaction without worrying about possible double spending. Quote What prevents Alice from spending one of the inputs of the timelocked transaction before it is included in any block? The network will see Alice->Bob transaction earlier than Alice->Daniel transaction and reject the second one as a double-spending attempt. A node should know all replaced transactions before doing a replacement, because it is needed to prove that it is not a double-spending attempt. Quote What about Bob's transaction and what's the point of including him in the chain if Alice in the end sends the payment directly to Charlie? It is needed as a proof that Alice->Charlie transaction is not a double-spending attempt, because Alice->Bob transaction was transmitted earlier.

Pages: [1] 2 »