Bitcoin Forum
May 08, 2024, 02:00:29 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 »
401  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core doesn't sign with Sighash_Single if index is smaller than outcount on: August 29, 2019, 01:30:56 PM
Yeah, I figured it must have something to do with the way core deals with hashes.
The wiki article however should either use the correct form when it calls it a "hash" or be explicit about the endianness and the type of it (being uint256).
Someone with edit access should clarify it IMO.
402  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core doesn't sign with Sighash_Single if index is smaller than outcount on: August 29, 2019, 10:51:02 AM
I'm confused about why bitcoin wiki is stating that the bytes to sign (or hash) should be
Code:
0000000000000000000000000000000000000000000000000000000000000001
whereas it is the exact opposite meaning what you sign is:
Code:
0100000000000000000000000000000000000000000000000000000000000000
meaning a byte array of length 32 and value 1 is set in its first position!


Here is the test transaction:
TxId: https://live.blockcypher.com/btc-testnet/tx/a9bc0f6129bc552379a20ab2a4b6a79ccc2d713acc99bf1b116939393646a5c3/
Third input signature was generated this way:
Code:
Message (hex): 0100000000000000000000000000000000000000000000000000000000000000
e (integer): 452312848583266388373324160190187140051835877600158453279131187530910662656
k (integer): 32569526756695674143942276415017767656920268428945073886134926826167993959331
key (integer): 84383840204293825554234399499853084747046055893341335473786835522085952287264

R: 00d22c986e5ccdf63c5714dafb24b73651d8658a3d2f185b39d82d8d1db93ff7d3
S: 0709f363ab3f36ca1fe01707fb018f5307f59a943a79b3fa101aa7a010905589
SigHashType: 03
Pubkey: 0305b3f3dc092ba4f8d79a16088dddd1fffb68871f590c69a2ebc4145be0ca648e

As it can be seen from e we aren't signing "1", we are signing 4523....56


And finally here is another one with both Single and AnyoneCanPay:
https://live.blockcypher.com/btc-testnet/tx/5b869dd7433a696b34a9ab3f86723ee2e04aad90932ddfa9d72734171a57961b/
403  Bitcoin / Development & Technical Discussion / Bitcoin Core doesn't sign with Sighash_Single if index is smaller than outcount on: August 28, 2019, 05:20:39 AM
I'm testing edge cases:
Code:
signrawtransaction "0100000003993c71b921a95716fa0edfe46d0facd246b8b4d3ee3f0147c526194a1bc5654a01000000009bfffffffa8c89ca6adf7e05fbe85cd84a8c876943aad26c2a1fa39fe00af2e20789e584000000000037ffffff56756fc8abc4b063a2bfbd1890a3c50c77c20bd7d0040002b1324d618f41140a0100000000d3feffff0230561a00000000001976a91433504f2fb2c368480cfba7530757d14c41c8960788ac40420f00000000001976a9147adb657ea875b9d684bbb43e528d7f120ffa67f988ac060d1800" '[{"txid":"0a14418f614d32b1020004d0d70bc2770cc5a39018bdbfa263b0c4abc86f7556","vout":1, "scriptPubKey":"76a91435d70ed960e3f83f83251a519cbc40178ff90d0788ac"}]' '["_key_removed_on_purpose_"]' 'SINGLE'
It is signing the third input with Sighash_Single (same with |AnyoneCanPay added) while having 2 outputs

This was bitcoin core 16.3 and it fails:
Code:
"Unable to sign input, invalid stack size (possibly missing key)"
Signing works with other SigHashTypes

The way I understand, this is allowed in protocol, it just doesn't make sense to sign this way (not having an actual txout to sign with Single!) and it should sign 32 byte long "1" instead.
Am I missing something or is it intentionally being rejected since it doesn't make sense to sign like this? If intentional is there any workaround other than signing with my code and broadcasting to see if it is rejected?
404  Bitcoin / Electrum / Re: [SECURITY/PRIVACY WARNING] Electrum console content is being stored on disk on: August 15, 2019, 06:48:24 PM
Note that the file stores "everything" you type in your console including wrong commands or any random string you type there. The first line in my file content example is exactly what it says it is, "random stuff". Trimming won't work in this case when the interpreter can not parse the data to know what its type is.
IMO there simply is no need for persistence of console history after the wallet is closed.
405  Bitcoin / Electrum / [SECURITY/PRIVACY WARNING] Electrum console content is being stored on disk on: August 15, 2019, 04:58:36 AM
If you have ever used Electrum's console tab and written anything there (not just successful commands), it is stored on your disk and you may want to clear it for either privacy reasons (eg. used ismine() and don't want to have that public information ie address here be stored on disk unencrypted) or for security reasons (eg. in case you used any of the functions like convert_xkey that involve something sensitive like your private key,...)

I've already opened an issue: https://github.com/spesmilo/electrum/issues/5563

To see this history you have to find your "config" file. It is located in the same place where your wallet folder is. On windows it will be
Code:
%APPDATA%\Electrum
On Linux or Mac:
Code:
~/.electrum

The file is simply called config (without an extension) and can be opened with any text editor. The content would look like this:
Code:
{
    "alias": "",
    "auto_connect": true,
    "check_updates": true,
    "config_version": 3,
    "console-history": [
        "random stuff",
        "ismine(\"Some address that you may not want to remain on disk for privacy reasons\")",
        "convert_xkey(\"master private key that holds your funds\", \"\")"
    ],
    "decimal_point": 8,
.....
}

The problem is the contents of console-history key. As you can see I wrote some examples already to show how it works.
In order to clean it manually you should first close your Electrum if it is open then delete everything after "console-history": [ starting after the opening bracket up to before the closing bracket without removing the brackets themselves. The result should be like this:
Code:
{
    "alias": "",
    "auto_connect": true,
    "check_updates": true,
    "config_version": 3,
    "console-history": [],
    "decimal_point": 8,
.....
}
406  Bitcoin / Development & Technical Discussion / Re: Is there a way to get the hash digest used for signing tx from bitcoin core? on: August 03, 2019, 04:54:26 PM
Are you sure that the private key you are providing is the correct format for uncompressed keys? It should begin with a 9, not a c.

Thanks, that was it. I forgot to change my isCompressed for this output to false when printing that command.
407  Other / Beginners & Help / Re: Prove the existence of documents using the Blockchain on: August 03, 2019, 03:34:04 PM
Any some best cases or situation that we can use this?
And do you know some website can do this or tutorial how we can do it by ourself only?

What this really is, is a method of inserting any kind of raw data in an immutable, decentralized and public ledger. This "data" can be anything you want because bitcoin doesn't care about the content of this special output. It is known as OP_RETURN outputs.

The way to do it is as simple as creating a new output with 0x6a or OP_Return and follow that up with a push of your data up to the specified maximum size.

Now that we've defined it, we can come up with use cases:
- Plain text
Example transaction
6a-13-636861726c6579206c6f766573206865696469 = <OP_Return> <PushData> charley loves heidi

- Hash of documents
You've already provided an example for documents. Another real world example is the government of Georgia that have been using bitcoin's blockchain for land registry with the help of Bitfury ever since 2016.

- Omni layer
https://github.com/OmniLayer/spec
https://medium.com/omnilayer/optimizing-the-payloads-of-omni-layer-transactions-ccb0a867da5d

- Mining altcoins!
I believe it is called Proof-of-Proof and is what Veriblock is using.

- Server-less & domain-less websites
This is a combination of torrents and bitcoin blockchain. https://github.com/elendirx/web2web

- TLS Certificates
A more advanced version of X.509 infrastructure using bitcoin's blockchain and OP_Return outputs for revocation of certificates and self-signed certificates
https://github.com/ChristopherA/revocable-self-signed-tls-certificates-hack

This article has some statistical information about OP_Return cases: https://www.researchgate.net/publication/313365747_An_analysis_of_Bitcoin_OP_RETURN_metadata
408  Bitcoin / Development & Technical Discussion / Is there a way to get the hash digest used for signing tx from bitcoin core? on: August 03, 2019, 03:01:07 AM
When signing a transaction, before passing the data to ECDSA related function it is hashed using SHA256x2, BIP143 refers to them as "sigHash". I was wondering if there was a way to get them for any given transaction using bitcoin core, or if they could be found among test cases.
They are very useful for testing specific part of the code instead of just testing the end result (signed transaction).


I also need help figuring out why bitcoin core can not sign the following:
Code:
signrawtransactionwithkey "0200000002aecc62c5db92bb213a0bfdfd3e15aab7367c06ce995ec30936b08b40c513b0560100000000ffffffffaecc62c5db92bb213a0bfdfd3e15aab7367c06ce995ec30936b08b40c513b0560200000000ffffffff0160e31600000000001976a91468cfed146aced22f422a68015ff8ca180761912a88acffffffff" '["_removed_base58_privatekey_"]' '[{"txid":"56b013c5408bb03609c35e99ce067c36b7aa153efdfd0b3a21bb92dbc562ccae", "vout":1, "scriptPubKey":"4104692d8520af5ac174143a928998fd9e8bd767bfd90fc1815e927bc84fdaf912e6687fe598ea324f25890abceb8d99040f70c35f8fd9e82ee206d19f963922dc16ac"}]'

I can sign the other output (vout=2) with the scriptpubkey of 2102fbbd836e18cb88f6dad65ca12dee3270b57818dd91a1cd500dd4c812ed93651cac and a different private key but this one (vout=1) which has a scriptpubkey with an uncompressed public key, fails.
The error message is:
Code:
Unable to sign input, invalid stack size (possibly missing key)
... using Bitcoin Core v0.18.0 (64-bit) testnet on Ubuntu 14.04, offline (no blockchain) and the private key is the correct one (will give the same public key)
409  Bitcoin / Project Development / Re: [C#] Watch Only Bitcoin Wallet. Support SegWit and Forks (V3.1) on: July 29, 2019, 06:12:10 AM
My suggestion is to add a column that has a value of "value at time of transaction", this would be extremely useful for, for instance, dealing with taxes when you have a ton of transactions. The value could be fetched from blockchain.info for instance, im not sure about their API but I have been using that site to manually check the value of BTC in fiat at the time a particular transaction happened. I don't know any software or website that does this so manually put it inside an .csv which is annoying. Would be cool if you could dump an export .csv from Core's client into your software and get this column neatly displayed.

I've added "price history" feature that will add a new field to each transaction based on its confirmation time that includes the USD value of that transaction at that time. It will use CoinDesk API since it is more common as an average price source.

The problem is that I'm not sure how to display this feature. For now you can only update this through the ForkBalance window and there is no displaying option but you could use your wallet.json file to analyze if you wanted. I'll probably do some major changes in this app as soon as I get some more free time, making things more automated and update everything in one place and skip repetition (since some parts are updated multiple times even if you already have the history).
Do you have any suggestions for displaying it? I was thinking a line chart showing the history.

As for bitcoin-core compatibility I have it in my TODO list but it is at the bottom of it.
410  Bitcoin / Development & Technical Discussion / Re: Why does P2SH script design look like a hack to me? on: July 28, 2019, 07:02:44 AM
Code:
05 52 53 93 55 87 | a9 14 4254e2a76ec94641c2d3e4b5528bbb30a350838c 87
Update:
First hash160 posted in this quote was used to create a new P2SH address (2MyHxGtCH53AhhWTzqwRRCq3MUZ5DahmhRi1) and some testNet coins were sent to this address in this transaction: 4bb9f0a567e83f8ef3b5a18d9b2b19e1139f302471ad03246be50598151d019a
This is the PubScript in this transaction:
a9-14-4254e2a76ec94641c2d3e4b5528bbb30a350838c-87

Then the coins were spent in this transaction: 463782617f0e6a69102530caa9ba2fe48f996128378af99ee437a22660afc5a7
The following is the complete hex dump of it (ScriptSig is in bold):
02000000
01
9a011d159805e56b2403ad7124309f13e1192b9b8da1b5f38e3fe867a5f0b94b
00000000
06
05 52-53-93-55-87
ffffffff
01
a086010000000000
19
76 a9 14 68cfed146aced22f422a68015ff8ca180761912a88ac
00000000


The "script" is the 52-53-93-55-87 (=OP_2 OP_3 OP_ADD OP_5 OP_EQUAL) and is placed in a OP_PUSH (05).
The preceding 06 is the CompactInt size of the whole scriptSig.

1. This address contains coins from 2018, apparently someone else did the same thing as me but never spent the coins. I won't touch them in case some other developer wanted to claim them as an exercise.
411  Bitcoin / Electrum / Re: How to import 2-of-3 multi-sig keys to Electrum wallet? on: July 28, 2019, 05:38:45 AM
https://github.com/spesmilo/electrum/issues/5535
412  Bitcoin / Development & Technical Discussion / Re: Why does P2SH script design look like a hack to me? on: July 26, 2019, 06:02:55 PM
Because that only works for multisig. P2SH allows you to do much more than just multisig. This is not a generic solution at all. Furthermore, you still have to have the "hack" of interpreting the top stack item as a script. The thing that you are calling a "hack" is just part of the literal definition of how to handle a P2SH scriptPubKey. P2SH just defined that a certain sequence of bytes are magic and you must do these specific things to handle them. You say that the script doesn't tell you to keep a copy of the script, but it does, because that's what the sequence of bytes that match the P2SH template means.

Thanks, it is starting to make more sense now. 1 more question though, does this mean I can put any "script" in my scriptSig that I want? For example is the following correct:
Code:
<PushData-redeem_script>|<Hash160><PushData-20_byte_hash><Equal>
I am skipping OP_0 since I don't have OP_CHECKMULTISIG and my redeem script is adding 2 + 3 and checks if it is 5:
Code:
05 52 53 93 55 87 | a9 14 4254e2a76ec94641c2d3e4b5528bbb30a350838c 87
413  Bitcoin / Development & Technical Discussion / Why does P2SH script design look like a hack to me? on: July 26, 2019, 03:36:06 PM
Since I am coding all these things without "translating" it from anywhere, I sometimes face some oddity in decisions that were made. Sometimes I am missing the rationale so here I am...

When looking at P2PKH scripts it all makes perfect sense:
Code:
<PushData-sig><PushData-pubkey>|<Dup><Hash160><PushData-20_byte_hash><EqualVerify><CheckSig>
Every "operation" does exactly what it says, they either push some data on top of stack or consume a number of items from the stack and interpret them specifically and give some result.

But then we have multisig/P2SH design the script stops making sense to me (a 2of3 example):
Code:
<0><PushData-sig1><PushData-sig2><PushData-redeem_script>|<Hash160><PushData-20_byte_hash><Equal>
Every operation is doing exactly what they are supposed to except the final PushData operation inside scriptsig! That one is not exactly pushing data, it is pushing a script which I also have to keep a copy of without the script telling me to!!! Which means my script runner now has to have (what I will be calling from now on) a "hack" that copies this last PushData first then runs the whole thing and then runs this last PushData as a script!

Logically running this script (without the hack) should be like this:

<OP_0> => stack has 1 item (emptyBytes)

<PushData-sig1> => stack has 2 item (empty-sig1)

<PushData-sig2> => stack has 3 items (empty-sig1-sig2)

<PushData-redeem_script> => stack has 4 items (empty-sig1-sig2-redeemScr)

<Hash160> => pop top item, hash it, push => stack has 4 items (empty-sig1-sig2-hashresult)

<PushData-20_byte_hash> => stack has 5 items (empty-sig1-sig2-hashresult-givenHash)

<Equal> => pop 2 and compare => stack has 4 items (empty-sig1-sig2-true/false)

Without the hack we are left with a stack with 4 items in it and no more operations left to run!

Now here is another question. Why not simply do this instead:
Code:
<PushData-sigs><PushData-redeem_script>|<Dup><Hash160><PushData-20_byte_hash><EqualVerify><CheckMultiSig>
Now this would not only make sense but also stick to the already existing design. The script "tells me" to duplicate the redeem script with its OP_DUP so I don't do it on my own, then perform the rest and finally the OP_CHECKMULTISIG consumes 2 items (just like its CheckSig counterpart) and interprets the first as a redeem script and the second as the number of required signatures. It also requires less number of push operations so the transaction can be a little smaller the more signatures it has! That could have maybe solve the OP_0 bug(?)
414  Bitcoin / Bitcoin Technical Support / Re: Need help with 24 word mnemonic on: July 23, 2019, 05:03:20 PM
Is it possible to make it so it checks for 24 word seeds and also without having to provide atleast 1 address?
Basicly i need it to just give all checksum passed seeds from 24 words.

With 24 words there are about 37*1021 combinations that have a valid checksum (about 6%). There is no point in having that much mnemonic. You need something to check against (like address) and discard each key as you check and go forward.
415  Bitcoin / Bitcoin Technical Support / Re: Need help with 24 word mnemonic on: July 23, 2019, 03:52:09 PM
This will check every possible combination of the seed and it will also generate many addresses to check.
You can lower the number of addresses generated if required..

I think the code might contain some issues. Also it would be great if you could leave some comments on it to explain what some functions are doing.
For starters it seems to be checking a seed with 12 words not 24.
The loop at the end also seems to be going from 0 to 1626 for some reason instead of 2048 (total number of words): for y in range(0,1626):
Also the words are out of order: "like", "just", "love",... is there any particular reason for it?
I also can't figure out why the seed is being added to itself and then hashed 100k times in function called stretch_key
And finally I was expecting to see HMAC-SHA512 a couple of times but haven't seen a single usage. So can you explain how this code is converting mnemonic to seed (PBKDF2) and also derive keys from the resulting seed?
416  Bitcoin / Development & Technical Discussion / In mining are the rest of target bytes 0 or 255? on: July 22, 2019, 07:08:18 AM
If nBits is 0x1b0404cb the target according to wiki is calculated as
Code:
0x00000000000404CB000000000000000000000000000000000000000000000000

so does this mean if the block hash was the following it would be rejected?
Code:
0x00000000000404CB000000000000000000000000000000000000000000000001

or do we set the remaining bytes in target to 0xff and then compare it with hash result? (Which means the above block hash could be accepted)
Code:
0x00000000000404CBFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
417  Alternate cryptocurrencies / Altcoin Discussion / Re: I have lost 8 letters of my Ethereum private key on: July 19, 2019, 01:41:41 PM
Considering the complexity of a wallet private key, the odds of guessing a 8-characters alphanumeric private keys are 1 in 2.1834E+14 (62^8). That's one in 218 trillion-plus. I don't think you have the chances of restoring those letters anymore.

Private keys aren't any random alphanumerics characters, they are usually encoded using some encoding scheme which means their set of characters are limited to a much smaller number.
In case of ethereum I believe it uses hexadecimal or base-16 encoding which means losing last 8 characters is equal to losing the last 4 bytes and the space to search is about 4.3 billion which is not that big a deal. But OP needs to have at least his address and preferably his public key to make this an easy possibility.
418  Bitcoin / Development & Technical Discussion / Re: For educational purposes, I've created a bitcoin miner! on: July 19, 2019, 08:48:43 AM
Since scrypt (used for Litecoin) is more complicated, I decided to start a visual demonstration of the algorithm and also did the same for Double_SHA256. Since the pictures are big here are the direct links:
SHA256: https://i.imgur.com/KhItpCG.jpg
scrypt: https://i.imgur.com/dfOwNyY.jpg
Hopefully they can help. I'll also publish the optimized version of scrypt algorithm soon.



419  Bitcoin / Development & Technical Discussion / Re: Significant Decimal Precision on: July 17, 2019, 05:30:41 AM
There are no decimal places in bitcoin and it is best we don't introduce them ever either. Floating point numeric types are a headache and can introduce bugs in a lot of implementations in different programming languages, not to mention they are slower.
With that said a simple solution can be this, which has the benefit of decreasing the transaction size too!
This is based on a naive research I did 2 years ago that showed changing every UInt32 in a block to CompactInt could empty the block size by up to 50 kilo bytes.

  • This assumes we do need this increase
  • For easy calculation price of bitcoin is assumed to be $1 million
  • Also the supply has to change from 21000000_00000000 to a fixed value of 21000000_00000000_00000000 (which is similar to 8 more decimal places)
The amount field in transactions can be changed from a UInt64 integral type to a new custom type that is similar to CompactInt but is mostly similar to what DER uses to encode lengths.
First bit, if set, indicates that first byte is the length of the bytes to read. The follow up bytes are the value itself.

To send $100 worth of bitcoin that is 0.00010000_00000000BTC in 16 decimal place representation and 0x0010a5d4e8 in little-endian hexadecimal representation we need 6 bytes. A first byte = 0x85(=0b10000101) followed by the amount. 0x850010a5d4e8. This saves up on 10 bytes.

This can be implemented using transaction version field. Every transaction that has version below 3 has amount field that is the current design of being a UInt64 and has to be multiplied by 108, every transaction with version 3+ has amount field set to the new format.

What this does is avoiding unnecessary complications while giving the implementations the advantage of speed and accuracy of regular integral numeric types. For 99% of the cases amounts sent are going to be smaller than a UInt64 so all the computations are fast and easy, anything bigger (worth >$1.84 billion) is going to be rare and computation requires 2 UInt64 which is still pretty easy, fast and 100% accurate.
Fee calculation and other conditions are still the same and easily calculated in this design.
420  Bitcoin / Bitcoin Technical Support / Re: [overview] Recover Bitcoin from any old storage format on: July 12, 2019, 03:55:25 AM
You can get a cheap letter punch on eBay, but most sets don't have lower case letters.

In these cases you can always change your encoding from any base to any other base that doesn't have mixed case digits. The most common is base-16 aka hexadecimal format, there is also base-36 (0-9 and a-z); neither one of these have the checksum that base-58 (WIF) has.
And finally there is bech32 which currently is only used for addresses but it can also be used for private keys although there is no standard for it yet but it offers the checksum and also error detection both of which are needed for storage purposes.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!