Search content
Sort by

Showing 20 of 21 results by coinlatte
Post
Topic
Board Development & Technical Discussion
Re: Wallet Label Export Format: A Proposal by Craig Raw
by
coinlatte
on 27/08/2022, 08:51:08 UTC
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.
Post
Topic
Board Development & Technical Discussion
Re: Wallet Label Export Format: A Proposal by Craig Raw
by
coinlatte
on 25/08/2022, 17:16:37 UTC
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.
Post
Topic
Board Development & Technical Discussion
Re: Intentionally make a transaction slower
by
coinlatte
on 02/05/2022, 19:04:04 UTC
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.
Post
Topic
Board Development & Technical Discussion
Merits 5 from 3 users
Topic OP
Multisig based on public key hashes instead of public keys
by
coinlatte
on 28/04/2022, 19:39:57 UTC
⭐ Merited by hugeblack (3) ,NeuroticFish (1) ,ETFbitcoin (1)
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.
Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: Importing taproot keys
by
coinlatte
on 24/11/2021, 18:25:00 UTC
⭐ Merited by garlonicon (1)
Quote
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)
Post
Topic
Board Development & Technical Discussion
Merits 2 from 2 users
Re: What happens in a copyright infringement scenario?
by
coinlatte
on 21/11/2021, 13:29:03 UTC
⭐ Merited by PrimeNumber7 (1) ,ETFbitcoin (1)
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.
Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Topic OP
Importing taproot keys
by
coinlatte
on 21/11/2021, 02:32:40 UTC
⭐ Merited by ertil (1)
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?
Post
Topic
Board Development & Technical Discussion
Merits 5 from 5 users
Topic OP
Representing fractional satoshis in difficulty-like format
by
coinlatte
on 12/04/2021, 13:35:45 UTC
⭐ Merited by odolvlobo (1) ,ETFbitcoin (1) ,NotATether (1) ,vapourminer (1) ,JayJuanGee (1)
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.
Post
Topic
Board Development & Technical Discussion
Re: Is this HD wallet secure?
by
coinlatte
on 06/03/2021, 14:02:33 UTC
It is just "firstAddedValue" multiplied by base point G.
Post
Topic
Board Development & Technical Discussion
Re: Is this HD wallet secure?
by
coinlatte
on 06/03/2021, 13:24:41 UTC
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.
Post
Topic
Board Development & Technical Discussion
Re: Is this HD wallet secure?
by
coinlatte
on 06/03/2021, 12:08:17 UTC
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 00000400


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.
Post
Topic
Board Development & Technical Discussion
Merits 2 from 2 users
Topic OP
Is this HD wallet secure?
by
coinlatte
on 06/03/2021, 08:39:46 UTC
⭐ Merited by NotATether (1) ,ETFbitcoin (1)
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?
Post
Topic
Board Announcements (Altcoins)
Re: [ANN][2POW] Luck - A new consensus algorithm to eliminate large mining pools
by
coinlatte
on 17/01/2021, 17:21:50 UTC
Now it works, but as I have less than 1 TB, I didn't mine any block so far.
Post
Topic
Board Announcements (Altcoins)
Re: [ANN][2POW] Luck - A new consensus algorithm to eliminate large mining pools
by
coinlatte
on 15/01/2021, 07:44:43 UTC
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.
Post
Topic
Board Announcements (Altcoins)
Re: [ANN][2POW] Luck - A new consensus algorithm to eliminate large mining pools
by
coinlatte
on 14/01/2021, 08:49:18 UTC
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.
Post
Topic
Board Development & Technical Discussion
Re: bitcoin-cli cold sign raw transaction
by
coinlatte
on 06/01/2021, 17:30:42 UTC
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.
Post
Topic
Board Development & Technical Discussion
Re: Is there any research on different key-value DBs suitable for bitcoin?
by
coinlatte
on 28/12/2020, 19:09:37 UTC
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.
Post
Topic
Board Development & Technical Discussion
Topic OP
Sending old blocks as compressed by default
by
coinlatte
on 26/12/2020, 22:35:42 UTC
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.
Post
Topic
Board Development & Technical Discussion
Re: Calculate z and z1 from ECDSA Signature
by
coinlatte
on 08/05/2020, 08:32:19 UTC
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 outputs, so for each of them you should create two different simplified transactions. Here is some example.
Post
Topic
Board Development & Technical Discussion
Re: Lightning Network over mempool using Replace By Fee
by
coinlatte
on 19/02/2020, 13:24:24 UTC
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.