There are two different encodings used.
Everything in the Bitcoin protocol, including transaction signatures and alert signatures, uses DER encoding. This results in 71 bytes signatures (on average), as there are several header bytes, and the R and S valued are variable length.
For message signatures, a custom encoding is used which is more compact (and ...
Your question seems to assume that the only goal is minimizing on-chain transaction size. Reducing size and related costs is certainly something that can be improved upon, but it's far from the only thing. The primary advantages of the Schnorr proposal are:
Better privacy, by making different multisig spending policies indistinguishable on chain. When ...
Disclaimer: I am going to assume that you are not completely clueless and that you know what an array is, how to count from 0, and how to match brackets, quotes, and colons so that you can read JSON formatted data. If you don't know how to do those things, then please google them first before reading this post.
Also, this post will be very long, and ...
Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA). Your private key is used to create the signature and your public key is used to verify the signature. This allows anybody to verify your signature as long as they have your public key.
For more detailed information: Digital Signature Algorithm and Elliptic Curve DSA
You can sign a message to prove ownership of a particular private key, without sharing the private key or spending any funds. For example, you could sign a message that says "My name is John Doe". You could give this signed message to anybody, and they can verify it with your public key. This proves that whoever has your private key claimed to be John Doe at ...
An algorithm called Public Key Recovery exists for ECDSA, which lets you construct the public keys for which a given pair of message and signature would be valid.
To explain the algorithm, remember that ECDSA signatures are pairs (r,s) for which sR = mG + rP. In this equation m is the message hash (which must be a hash of a known message), P is the public ...
The simple answer is no.
A hashing algorithm is ment to be a one-way function. If it is possible to recreate the public key from the hash, this means that the hashing algorithm is broken.
However there is one aspect that you might find useful. For message signatures, bitcoin uses a custom encoding (compared to the DER encoded signature found in ...
Yes, a transaction includes the public key. So, only when you spend the coins from an address a public key actually becomes public (unless you have shared it with anyone otherwise).
So, as long as you don't reuse addresses, the public key is only known after a transaction, which usually is just a few confirmations away from the address' balance to be 0.
Here are a few I'd recommend:
https://bitcore.io/playground/#/address (private key - public key)
https://brainwalletx.github.io/#generator (signing and verifying but bitcoin specific)
Or play with pybitcointools at the command line (not online):
$ git clone https://github.com/vbuterin/pybitcointools.git
$ cd pybitcointools
>>> from ...
bitcoinjs already has support for litecoin, a quick look at /src/network.js and the README reveals this.
See how they set the network: litecoin variable, that is probably used consistently through the code (atleast for address generation).
Nothing really major changes for ...
It shouldn't compromise the private key. Notice that publishing a message along with a signature is a common thing, and is necessary to verify the signature. Publishing also de Bitcoin address is similar to give the public key, since the former can be derived from the latter (actually, once you redeem your first transaction by signing it, you will provide ...
BIP 62 proposed to make transaction malleability impossible.
No it didn't. It would have outlawed a limited number of known and addressable forms of malleability.
In particular, it did not prevent multisig transaction participants from just creating a new signature, malleating the transaction without invalidation. This type of malleability is trivial to ...
No. This is not possible, although, technically it could be possible by adding n child transaction each formed as a tx out of you original transaction. The child transaction then could each have a OP_RETURN (data only) output. With a OP_RETURN output you can store up to 80 bytes (mind 5286). A DER signature will be around 72 Bytes (71.5 in avg)
... so not ...
Here is one possible idea that I believe is almost what you want and quite likely (or so I hope!) both good enough and actually particularly good by incentizing all involved parties to collaborate to that goal. The basic idea is to incentize the recipient to sign for reception in a way that prevents him from lying just to collect the incentive.
Use multisig ...
Yes. And it's pretty easy to understand why, without even mentioning anything about the underlying technologies.
A bitcoin: URL only contains the address of the recipient. The address does not need any previous transactions in the blockchain to resolve to a public key, so we can deduct that a bitcoin URL has the full public key.
When you spend bitcoins ...
closest I can come up with are these:
not exactly ECDSA, but served me alot for Bitcoin undertsanding/testing.
Security hint: you would never provide/...
You're seeing the effect of RFC6979.
When generating a signature, some randomness is needed (called the nonce), as there are multiple valid signatures for the same message/key pair. The algorithm used, ECDSA, is extraordinarily vulnerable to weak randomness. An attacker who knows just a slight bit of information about your nonces can learn your private key ...
1) Generate a random private key just to be used to prove ownership.
2) Create a message with the corresponding public key to the key generated in step one and the public key you wish to prove ownership of.
3) Sign it with both private keys.
4) Send it to a central authority.
5) Receive from the central authority a signed statement saying that ...
signmessage and verifymessage only work with legacy type addresses. They do not work with segwit addresses. There is ongoing work to introduce a new message signing standard that will work regardless of address type.
Some discussion about why they only work on legacy addresses can be found in this issue: https://github.com/bitcoin/bitcoin/issues/10542
The hardware wallet company sometimes runs a node, but you could just as easily use a client like Electrum instead, and use Electrum nodes instead with your hardware wallet. All the node is used for is checking for transactions and publishing transactions.
The wallet software will use the xpub from the hardware wallet to check for payments people have ...
The sign/verify message feature has nothing to do with the regular wallet functionality. Sending and receiving coins has nothing to with it.
It provides the ability to sign a message... anything you like, using one of your addresses, proving that you are the owner of the address. It can be used to prove you own some amount of bitcoins, without actually ...
Each input has its own and unique signature. This allows users to forge advanced transactions, such as offline signing where each participant agrees to provide inputs separately.
Even if all inputs belong to the same address, each one is signed separately (with the same private key in this case).
Oh, and multisignature addresses (P2SH, pay-to-script-hash) ...
Imagine if that weren't there. What if someone tricked you into signing a Bitcoin transaction with your key? They could put the signature they got from you along with your public key into the input script for the transaction, and broadcast that transaction to the network. (Unless something else I'm not aware of would prevent that.)
Granted, it would be ...
What you have come across is the yet to be fully explored world of cryptographic signatures - and this is only the beginning my friend.
A cryptographic signature in a very simplistic way, allows you to electronically sign something, usually a string of text. That signature can then be used to prove that the text that you signed has not been tampered with. ...
There are many command line tools for creating and signing raw transactions offline, most of them written in Python: pycoin, python-bitcoinlib, pybitcointools and others.
If you use Electrum wallet, it has command line tools for offline transaction creation and signing:
$ ./electrum help createrawtx
$ ./electrum help signtransaction
For example with bitcore-lib:
var Message = require('bitcore-message');
var privateKey = new bitcore.PrivateKey('L23PpjkBQqpAF4vbMHNfTZAb3KFPBSawQ7KinFTzz7dxq6TZX8UA');
var message = new Message('This is an example of a signed message.');
var signature = message.sign(...
It proves that you control all children of that address (i.e. the ones further down the chain). It does not prove that you own the parents of that address (i.e. the ones further up the chain), since it's not possible (AFAIK) to go from a child to a parent key.
Your signature is not correct. First of all, its length can't be 74 bytes long. According to the Bitcoin wiki:
Signatures are either 73, 72, or 71 bytes long, with probabilities approximately 25%, 50% and 25% respectively, although sizes even smaller than that are possible with exponentially decreasing probability.
Having said that, it seems that you ...