NiceHash - Leading Cryptocurrency Platform for Mining and ...

NiceHash - buy & sell hashing power

NiceHash offers you to buy or sell hashing power directly, no contracts, no limitations, pay-as-you-go if you're a buyer and be-paid-as-you-go if you're a seller. Why bother renting rigs, when you can rent hashing power? NiceHash brings more to renters and rig owners. Visit https://www.nicehash.com today! Simply create order and you are already mining your favorite coin or point your rig to our stratum server and you are already earning bitcoins.
[link]

HashFlare.io Cloud Mining

/HashFlareCloudMining/ Subreddit for HashFlare.io users.
[link]

Mining Bitcoin

Bitcoin mining is analogous to the mining of gold, but its digital form. The process involves specialized computers solving algorithmic equations or hash functions. These problems help miners to confirm blocks of transactions held within the network. Bitcoin mining provides a reward for miners by paying out in Bitcoin in turn the miners confirm transactions on the blockchain. Miners introduce new Bitcoin into the network and also secure the system with transaction confirmation.
[link]

This is how we will recover coins sent to the wrong address or an unowned address

Don't worry, I'm NOT advocating that transactions should be reversible.
Many of us have accidentally sent coins to the wrong address or an unowned address, resulting in those coins being permanently unrecoverable and unspendable. I haven't made this mistake (yet), but damn it makes me nervous when I send larger transactions.
Unfortunately, we'll never be able to revert those past mistakes, but with a small change to the bitcoin protocol, we can make it so that we can recover the coins when we make this sort of mistake in the future.
Please let me know your thoughts about my solution below, and if something like this is already in the works.

The solution, conceptually

If everybody knew everyone else's public keys, we could prevent these permanent mistakes with multisig scripts. The change I'm proposing will make it so we can prevent the mistakes without knowing each other's public keys, but I'll explain it in terms of multisig, because the solution is conceptually the same, and easier to explain:
Instead of sending coins directly to a recipient address, send your coins to a 1-of-2 multisig account, shared by both you and the recipient.
This means that effectively, the transaction is "cancellable", but only until the recipient sends the coins to his own account. At that point the coins are irreversibly his.
The downside of this is that when receiving a payment, you must explicitly accept it before the coins are truly yours -- you should not consider the coins as yours until you do this. The upside is that it guarantees that coins are never lost at inactive addresses.

Problems that this solves

  1. Sending to an unowned address (base58Check almost always protects against this)
  2. Sending to an address that was owned, but the private keys were lost and nobody has control of the address anymore
  3. Sending to the wrong (but owned) address, unless the unintended recipient is quick to claim the coins
  4. Sending your coins to the wrong address on an exchange (i.e. an address for a forked blockchain)

Implementation and technical details

We can accomplish the above without knowledge of each others' public keys, if we use a custom pubkey script. Nodes only accept transactions with standard pubkey scripts, so we'd need to define a new standard script.
The typical P2PKH script looks like this:
scriptPubKey: OP_DUP OP_HASH160 OP_DUP  OP_EQUALVERIFY OP_CHECKSIG scriptSig:   
The new standard script I'm proposing is this:
scriptPubKey: OP_DUP OP_HASH160 OP_DUP  OP_EQUAL OP_SWAP  OP_EQUAL OP_ADD OP_VERIFY OP_CHECKSIG ( would be your address, and  would be the recipient's address) scriptSig:   
This script allows the coins to be spent by either the owner of or .
I call this new transaction type Pay To Either Public Key Hash (P2EPKH), or colloquially, "fuck-up protection".
Of course, wallets would have to be able to recognize the new transaction type, and offer controls to claim coins from incoming P2EPKH transactions or to cancel unclaimed P2EPKH transactions.

Feedback, please.

What do you all think? Is this generally a decent idea? Has this idea been floated around before? Is there another solution for this issue in the works? If this is a good idea, how do I get the attention of the devs?
submitted by ransoing to btc [link] [comments]

Implementing full Internet IPv6 end-to-end encryption based on Cryptographically Generated Address

# Foreword

Encryption based on shared secrets

Symmetric encryption is based on shared keys, asymmetric encryption is based on shared public keys, and HTTPS is based on the browser's built-in CA root certificate.

There have been rumors that IPv6 can implement end-to-end encryption of all the Internet based on IPsec, but this is impossible.

IPsec is also based on passwords or certificates, and also requires shared secrets.

The problem is that there is no shared secret between us and strangers. Without the secret of sharing, we can't authenticate each other. If this problem is not solved, Internet end-to-end encryption is impossible.

But Cryptographically Generated Address (CGA) solves this problem because CGA turns the IPv6 address itself into a "shared secret."

# Cryptographically Generated Address

Detailed CGA information can be found in RFC 3972, I will briefly explain here.

CGA is used to implement Secure Neighbor Discovery, which resolves authentication without CA.

The CGA divides the IPv6 address into three parts, the first 64-bit subnet prefix, the middle 3 bits of computational difficulty, and the last 59 bits of the hash address generated based on the public key.

+-+-+-+-+-+-+-+-+-
| |
| modifier |
| |
+-+-+-+-+-+-+-+-+-
| |
| subnet prefix |
| |
+-+-+-+-+-+-+-+-+-
|collision count |
| |
| public key |
| |
+-+-+-+-+-+-+-+-+-
| |
| Extension Fields |
| |
+-+-+-+-+-+-+-+-+-

  1. Generate a 128-bit random value and fill in the modifier, set the network prefix and collision count to 0, and fill in the public key and extension field.

  1. Perform the hash on the above CGA data structure, and get the hash value of the first 112 bits as HASH2.

  1. If the first 16 * sec bit of HASH2 is 0, continue, otherwise the modifier increments by 1 and repeats the second step. This is a proof of workload, increasing the difficulty of hash collision.

  1. Fill in the actual network prefix, perform a hash on the CGA data structure, and record the first 64 bits of the hash value as HASH1.

  1. Cover the first 3 bits of HASH1 with sec. Now we get the CGA address. Combining the 64-bit network prefix with the CGA address is the complete IPv6 address.

  1. If an IPv6 address conflict occurs and someone has used this address, increase the collision count and return to step 4.

The above is the process of CGA generating IPv6 address. We successfully associate the public key with the IPv6 address. No CA is needed. The IPv6 address contains the shared secret.

Now we can send the public key to the stranger and sign it with the private key. MITM cannot replace the public key. Because there is a hash of the public key in the IPv6 address, the public key cannot be forged.

In Secure Neighbor Discovery, CGA is used to prevent impersonation of NA messages, similar to ARP spoofing attacks, to prevent contamination of MAC addresses in cache tables.

The private key signs the MAC address, and the NA message of the signature and the public key is sent to the other party. The other party verifies the public key according to the hash in IPv6, and verifies the signature, so that the person who forges the NA message has no way to start.

# IPv6 Secure Encryption Protocol

I think CGA is too wasteful if it is only used in Secure Neighbor Discovery.

CGA can be used on the entire Internet!

CGA solves the problem of shared secrets, we can use CGA to achieve end-to-end encryption of the entire Internet.

When we connect to the Internet, the router will send us RA messages, the RA contains the subnet prefix, we can use CGA to generate its own public key, private key, IPv6 address.

When we communicate with strangers, we can use the following handshaking protocol.

Public key, the Diffie-Hellman key, and the signature of the DH-Key can be stored in the extended header of IPv6

pub-A dh-A sign-A
  1. Alice --------------------- Bob

pub-B dh-B sign-B
  1. Alice <----------------------- Bob

encrypt data
  1. Alice --------------------- Bob

encrypt data
  1. Alice <----------------------- Bob

  1. Alice sends the public key, the Diffie-Hellman key, and the signature of the DH-Key with the private key. When Bob receives the message, the public key is verified by CGA. The public key verifies the signature, and DH-Key can be used to generate its own AES password.

  1. Bob replies to the same message from Alice, and Alice also generates her own AES key.

  1. and 4. Now both parties have the same AES key and can encrypt the IPv6 payload.

# Frequently Asked Questions:

  1. Why not use TLS?

Because TLS requires CA, or share the public key in advance.TLS is an application layer protocol that requires developers to configure itself, not a general solution.

I think the Internet needs network layer encryption. Network layer encryption can hide port information. You can't listen to web, dns, ftp at 443 at the same time. Governments and hackers can view the services you are using based on port information.

And encryption at the network layer can protect many plaintext protocols. After all, we can't let everyone use TLS to protect themselves. There should be a way to protect those old servers and those who don't know how to use TLS.

  1. Is the 59-bit hash enough to resist a collision attack?

Network layer encryption is mainly used to provide basic security mechanisms, similar to social insurance. If a higher level of security is required, other protocols can be used at the application layer. The 59-bit hash has proof of workload when calculating hashes, which I think is sufficient to defend against ordinary attackers.

  1. Are there other programs that use CGA-like functions?

Tox (encrypted instant communication), generating the address of the DHT network based on the public key

Bitcoin, generating a wallet address based on the public key

  1. What if the encrypted IPv6 packet is lost?

The network layer is not responsible for the integrity of the data, and the retransmission is the responsibility of the transport layer.

  1. What if lose packets when handshaking?

If Alice's handshake packet is lost, Alice is responsible for retransmission.

pub-A dh-A sign-A
  1. Alice --------------------- Bob lost

pub-A dh-A sign-A
  1. Alice --------------------- Bob retransmission

If Bob's handshake packet is lost, Alice will retransmit his handshake packet, and Bob will send his handshake packet again after receiving it.

If Bob sends its own encrypted message before retransmission, it is ignored because the network layer is not responsible for data integrity and waits for the transport layer to retransmit.

Network layer encryption does not use a three-dimensional handshake like TCP.

pub-A dh-A sign-A
  1. Alice --------------------- Bob

pub-B dh-B sign-B
  1. Alice <----------------------- Bob

encrypt data
  1. Alice <----------------------- Bob

pub-A dh-A sign-A
  1. Alice --------------------- Bob retransmission

pub-B dh-B sign-B
  1. Alice <----------------------- Bob retransmission

encrypt data
  1. Alice <----------------------- Bob


# idea

If we can encrypt at the network layer, I think traffic identification can be a thing of the past, and the Internet is ushered in a new era.

What do you think of this idea?
submitted by ttttabcd to ipv6 [link] [comments]

Implementing full Internet IPv6 end-to-end encryption based on Cryptographically Generated Address

# Foreword

Encryption based on shared secrets

Symmetric encryption is based on shared keys, asymmetric encryption is based on shared public keys, and HTTPS is based on the browser's built-in CA root certificate.

There have been rumors that IPv6 can implement end-to-end encryption of all the Internet based on IPsec, but this is impossible.

IPsec is also based on passwords or certificates, and also requires shared secrets.

The problem is that there is no shared secret between us and strangers. Without the secret of sharing, we can't authenticate each other. If this problem is not solved, Internet end-to-end encryption is impossible.

But Cryptographically Generated Address (CGA) solves this problem because CGA turns the IPv6 address itself into a "shared secret."

# Cryptographically Generated Address

Detailed CGA information can be found in RFC 3972, I will briefly explain here.

CGA is used to implement Secure Neighbor Discovery, which resolves authentication without CA.

The CGA divides the IPv6 address into three parts, the first 64-bit subnet prefix, the middle 3 bits of computational difficulty, and the last 59 bits of the hash address generated based on the public key.

+-+-+-+-+-+-+-+-+-
| |
| modifier |
| |
+-+-+-+-+-+-+-+-+-
| |
| subnet prefix |
| |
+-+-+-+-+-+-+-+-+-
|collision count |
| |
| public key |
| |
+-+-+-+-+-+-+-+-+-
| |
| Extension Fields |
| |
+-+-+-+-+-+-+-+-+-

  1. Generate a 128-bit random value and fill in the modifier, set the network prefix and collision count to 0, and fill in the public key and extension field.

  1. Perform the hash on the above CGA data structure, and get the hash value of the first 112 bits as HASH2.

  1. If the first 16 * sec bit of HASH2 is 0, continue, otherwise the modifier increments by 1 and repeats the second step. This is a proof of workload, increasing the difficulty of hash collision.

  1. Fill in the actual network prefix, perform a hash on the CGA data structure, and record the first 64 bits of the hash value as HASH1.

  1. Cover the first 3 bits of HASH1 with sec. Now we get the CGA address. Combining the 64-bit network prefix with the CGA address is the complete IPv6 address.

  1. If an IPv6 address conflict occurs and someone has used this address, increase the collision count and return to step 4.

The above is the process of CGA generating IPv6 address. We successfully associate the public key with the IPv6 address. No CA is needed. The IPv6 address contains the shared secret.

Now we can send the public key to the stranger and sign it with the private key. MITM cannot replace the public key. Because there is a hash of the public key in the IPv6 address, the public key cannot be forged.

In Secure Neighbor Discovery, CGA is used to prevent impersonation of NA messages, similar to ARP spoofing attacks, to prevent contamination of MAC addresses in cache tables.

The private key signs the MAC address, and the NA message of the signature and the public key is sent to the other party. The other party verifies the public key according to the hash in IPv6, and verifies the signature, so that the person who forges the NA message has no way to start.

# IPv6 Secure Encryption Protocol

I think CGA is too wasteful if it is only used in Secure Neighbor Discovery.

CGA can be used on the entire Internet!

CGA solves the problem of shared secrets, we can use CGA to achieve end-to-end encryption of the entire Internet.

When we connect to the Internet, the router will send us RA messages, the RA contains the subnet prefix, we can use CGA to generate its own public key, private key, IPv6 address.

When we communicate with strangers, we can use the following handshaking protocol.

Public key, the Diffie-Hellman key, and the signature of the DH-Key can be stored in the extended header of IPv6

pub-A dh-A sign-A
  1. Alice --------------------- Bob

pub-B dh-B sign-B
  1. Alice <----------------------- Bob

encrypt data
  1. Alice --------------------- Bob

encrypt data
  1. Alice <----------------------- Bob

  1. Alice sends the public key, the Diffie-Hellman key, and the signature of the DH-Key with the private key. When Bob receives the message, the public key is verified by CGA. The public key verifies the signature, and DH-Key can be used to generate its own AES password.

  1. Bob replies to the same message from Alice, and Alice also generates her own AES key.

  1. and 4. Now both parties have the same AES key and can encrypt the IPv6 payload.

# Frequently Asked Questions:

  1. Why not use TLS?

Because TLS requires CA, or share the public key in advance.TLS is an application layer protocol that requires developers to configure itself, not a general solution.

I think the Internet needs network layer encryption. Network layer encryption can hide port information. You can't listen to web, dns, ftp at 443 at the same time. Governments and hackers can view the services you are using based on port information.

And encryption at the network layer can protect many plaintext protocols. After all, we can't let everyone use TLS to protect themselves. There should be a way to protect those old servers and those who don't know how to use TLS.

  1. Is the 59-bit hash enough to resist a collision attack?

Network layer encryption is mainly used to provide basic security mechanisms, similar to social insurance. If a higher level of security is required, other protocols can be used at the application layer. The 59-bit hash has proof of workload when calculating hashes, which I think is sufficient to defend against ordinary attackers.

  1. Are there other programs that use CGA-like functions?

Tox (encrypted instant communication), generating the address of the DHT network based on the public key

Bitcoin, generating a wallet address based on the public key

  1. What if the encrypted IPv6 packet is lost?

The network layer is not responsible for the integrity of the data, and the retransmission is the responsibility of the transport layer.

  1. What if lose packets when handshaking?

If Alice's handshake packet is lost, Alice is responsible for retransmission.

pub-A dh-A sign-A
  1. Alice --------------------- Bob lost

pub-A dh-A sign-A
  1. Alice --------------------- Bob retransmission

If Bob's handshake packet is lost, Alice will retransmit his handshake packet, and Bob will send his handshake packet again after receiving it.

If Bob sends its own encrypted message before retransmission, it is ignored because the network layer is not responsible for data integrity and waits for the transport layer to retransmit.

Network layer encryption does not use a three-dimensional handshake like TCP.

pub-A dh-A sign-A
  1. Alice --------------------- Bob

pub-B dh-B sign-B
  1. Alice <----------------------- Bob

encrypt data
  1. Alice <----------------------- Bob

pub-A dh-A sign-A
  1. Alice --------------------- Bob retransmission

pub-B dh-B sign-B
  1. Alice <----------------------- Bob retransmission

encrypt data
  1. Alice <----------------------- Bob


# idea

If we can encrypt at the network layer, I think traffic identification can be a thing of the past, and the Internet is ushered in a new era.

What do you think of this idea?
submitted by ttttabcd to crypto [link] [comments]

Trying to get a deeper understanding of atomic swaps

Hi together,
I'm an IT-student and writing a thesis about atomic swaps on BTC and BTC-like blockchains. For the thesis I decided to use BTC, LTC, BCH and DCR. These chains have a somehow similar codebase and the same scripting language (I'm not a professional, so there might be differences, but they are not that serious). And they all have a high enough marketcap to be relevant for atomic swaps.
So the goal of the thesis is to find hashed timelock contracts (HTLCs) and connect matching HTLCs from different chains to get the atomic swap. Therefore I first searched the web for anything on atomic swaps [1] and analyzed the input script of this transaction [2] to get a basic understanding how atomic swaps work and what they look like.
Then I wrote a go program to search for any script longer than simple P2PKH scripts. This gave me a list of many different scripts which I analyzed by hand to only take the HTLC ones. (Besides many multisig scripts, there is not much to find on BTC^^)
At this point I found multiple different types of HTLCs as listed below. Afterwards I crawled* BTC again saving all transactions with HTLC scripts, storing the interesting data like tx-id, input value, pubKeyHashes, the secrets and their hashes. I found about one hundret HTLCs on BTC so far.
I did the same for LTC and found about 400 HTLCs.
As far as I understood, the secrets of HTLCs have to be the same on both chains. So I wrote another go program to match the found HTLCs from BTC and LTC and got around 30 matches. The next steps would then be to crawl BCH and DCR and also match the HTLCs found there.
* Crawling in this case means that I start to search the blockchain backwards (to get the newest first, the beginning years are not that interesting in this case^^) until the beginning of 2017. So about 18 months. As stated in [1] the first known atomic swap between BTC and LTC was made on 19th April 2017 (or April 19th 2017 or 19.4.2017 or whatever you like). So there is not much sense in crawling any further.
My questions now are the following:
I'm open to any constructive input and hope you have a few answers for me. Thank you in advance.
Type 1: sha256 secret, length=97byte
63 if 82 size 01 data1 20 88 equalverify a8 sha256 20 data32  88 equalverify 76 dup a9 hash160 14 data20  67 else 04 data4  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 2a: sha256 secret, length=94byte
63 if a8 sha256 20 data32  76 dup a9 hash160 14 data20  88 equalverify ac checksig 67 else 04 data4  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  88 equalverify ac checksig 68 endif 
Type 2b: sha256 secret, length=93byte
63 if a8 sha256 20 data32  88 equalverify 76 dup a9 hash160 14 data20  67 else 04 data4  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 3: ripemd160 secret, length=81byte
63 if a6 ripemd160 14 data20  88 equalverify 76 dup a9 hash160 14 data20  67 else 04 data4  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 4a: hash160 secret, length=86byte
63 if 03 data3  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  88 equalverify ac checksig 67 else 76 dup a9 hash160 14 data20  88 equalverify ad checksigverify 82 size 01 data1 21 -> 33 88 equalverify a9 hash160 14 data20  87 equal 68 endif 
Type 4b: hash160 secret, length=82byte
63 if 03 data3  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  88 equalverify ac checksig 67 else 76 dup a9 hash160 14 data20  88 equalverify ad checksigverify a9 hash160 14 data20  87 equal 68 endif 
Type 5a: hash160 secret, length=81byte
63 if a9 hash160 14 data20  88 equalverify 76 dup a9 hash160 14 data20  67 else 04 data4  b2 checksequenceverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 5b: hash160 secret, length=78byte
63 if a9 hash160 14 data20  88 equalverify 76 dup a9 hash160 14 data20  67 else 01 data1  b2 checksequenceverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 6: hash160 secret, length=79byte
63 if 54  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  88 equalverify ac checksig 67 else 76 dup a9 hash160 14 data20  88 equalverify ad checksigverify a9 hash160 14 data20  87 equal 68 endif 
Type 7: multiple ripemd160 secrets, length=80 + n*23byte
63 if a6 ripemd160 14 data20  88 equalverify a6 ripemd160 14 data20  ... 88 equalverify a6 ripemd160 14 data20  88 equalverify 21 data33  ac checksig 67 else 04 data4  b1 checklocktimeverify 75 drop 21 data33  ac checksig 68 endif 
Type 8: multiple ripemd160 secrets, length=81 + n*23byte
74 depth 60 16 87 equal 63 if a6 ripemd160 14 data20  88 equalverify a6 ripemd160 14 data20  ... 88 equalverify a6 ripemd160 14 data20  88 equalverify 21 data33  67 else 03 data3  b1 checklocktimeverify 75 drop 21 data33  68 endif ac checksig 
[1] http://www.cryptovibes.com/crypto-news/charlie-lees-atomic-swap-between-litecoin-and-bitcoin-was-a-success/
[2] https://insight.bitpay.com/tx/0bb5a53a9c7e84e2c45d6a46a7b72afc2feffb8826b9aeb3848699c6fd856480
submitted by noobWithAComputer to Bitcoin [link] [comments]

Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY | Rune K. Svendsen | Sep 17 2016

Rune K. Svendsen on Sep 17 2016:
I would really like to be able to create transactions that are immune to
transaction ID malleability now, so I have been thinking of the simplest
solution possible, in order to get a BIP through without too much trouble.
An opcode we could call OP_TXHASHVERIFY could be introduced. It would be
defined to work only if added to a scriptSig as the very first operation,
and would abort if the hash of the transaction **with all OP_TXHASHVERIFY
operations (including stack push) removed** does not match what has been
pushed on the stack.
So, in order to produce a transaction with one or more inputs protected
against tx ID malleability, one would:
  1. Calculate tx ID of the tx: TX_HASH
  2. For each input you wish to protect, add "0x32 $TX_HASH OP_TXHASHVERIFY"
to the beginning of the scriptSig
When evaluating OP_TXHASHVERIFY, we make a copy of the tx in question, and
remove the "0x32 <32 bytes> OP_TXHASHVERIFY" sequence from the beginning of
all scriptSigs (if present), and abort if the tx copy hash does not match
the top stack item.
This is a very simple solution that only adds 34 bytes per input, and when
something better becomes available (eg. Segwit), we will stop using this.
But in the meantime it's very valuable to be able to not worry about tx ID
malleability.
Please let me know what you think.
 /Rune 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160917/3a30a98c/attachment.html
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Septembe013116.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

SCRY.INFO underlying double chain technology sharing

SCRY.INFO underlying double chain technology sharing
1.Background
In SCRY project, double chain structure is applied in clients. As for signature algorithm, we selected BIP143. In segregated witness, VERSION 0 applied BIP143 signature verification to increase efficiency, but BIP143S algorithm is not applied to general transactions. We have optimized general transaction signature and verification, apply BIP143 signature and verification to increase the efficiency.
1.1Signature algorithm
Bitcoin applied ECDSA (Elliptic Curve Digital Signature Algorithm) as digital signature algorithm. There are 3 use cases of digital signature algorithm in Bitcoin: 1. Signature can verify the owner of private key, the owner of money transferring in that transaction. 2. The proxy verification cannot be denied, that is the transaction cannot be denied. 3. The signature cannot be falsified, that is transaction (or details of transaction) cannot be adjusted by anyone after signature.
There are two parts of digital signature: one is using private key( signature key) to sign the hash of message(transaction), the other one is to allow everyone can verify the signature by provided public key and information.
  • Signature algorithm
The signature algorithm of Bitcoin is as following:
Sig = Fsig( Fhash(m), dA )
Explanation:
dA is private key signature
m is transaction (or part of transaction)
Fhash is hash function
Fsig is signature algorithm
Sig is result signature
There are 2 functions in the whole signature: Fhash and Fsig。
  • Fhash function
Fhash function is to generate Hash of transaction, first serialize the transaction, based on serialized binary data use SHA256 to calculate the transaction Hash. The general transaction (single input and single output) process is as following:
Transaction serialization:
1.nVersion Transaction version
2.InputCount Input count
3.Prevouts Serialize the input UTXO
4.OutputCount Output count
5.outpoint Serialize the output UTXO
6.nLocktime Locked period of transaction
7.Hash Twice SHA256 calculation based on the data above
  • Fsig function
Fsig function signature algorithm is based on ECDSA. There will be a K value every encryption. Based on this K value, the algorithm will generate a temporary public/private key (K,Q), select X axis of public key Q to get a value R, the formula is as following:
S=K-1 *(Hash(m) + dA *R) mod p
Explanation:
K is temporary private key
R is x axis of temporary public key
dA is signature private key
m is transaction data
p is the main sequence of elliptical curve
The function will generate a value S.
In elliptical curve every encryption will generate a K value. Reuse same K value will cause private key exposed, K value should be seriously secured. Bitcoin use FRC6979 TO ensure certainty, use SHA256 to ensure the security of K value. The simple formula is as following:
K =SHA256(dA+HASH(m))
Explanation,
dA is private key,
m is message.
Final signature will be generated with the combination of ( R and S)
  • Signature verification
Verification process is applying signature to generate inverse function, the formula is as following:
P=S-1 *Hash(m)*G +S-1*R*Qa
Explanation:
R and S are signature value
Qa is user(signer)’s public key
m is signed transaction data
G is generator point of elliptical curve
We can see from this formula, based on information (transaction or part of Hash value), public key and signature of signer(R and S value), calculate the P value, the value will be one point on elliptical curve. If the X axis equals R, then the signature is valid.
1.2

Bip143 brief introduction

There are 4 ECDSA (Elliptic Curve Digital Signature Algorithm) signature verification code(sigops):CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY. One transaction abstract will be SHA256 encryption twice.There are at least 2 disadvantages in Bitcoin original digital signature digest algorithm:
●Hash used for data verification is consistent with transaction bytes. The computation of signature verification is based on O(N2) time complexity, time for verification is too long, BIP143 optimizes digest algorithm by importing some “intermediate state” which can be duplicate, make the time complexity of signature verification turn into O(n).
●The other disadvantages of original signature: There are no Bitcoin amounts included in signature when having the transaction, it is not a disadvantage for nodes, but for offline transaction signature devices (cold wallet), since the importing amount is not available, causing that the exact amount and transaction fees cannot be calculated. BIP143 has included the amount in every transaction in the signature.
BIP143 defines a new kind of task digest algorithm, the standard is as following:
Transaction serialization
https://preview.redd.it/2b6c5q2mk7b11.png?width=783&format=png&auto=webp&s=eb952782464942b6930bbd2632fbcd0fbaaf5023
1,4,7,9,10 in the list is the same as original SIGHASH algorithm, original SIGHASH type meaning stay the same. The following contains are changed:
  • Serialization method
  • All SIGHASH commit amount for signature
  • FindAndDelete signature is not suitable for scripteCode;
  • AfterOP_CODESEPARATOR(S),OP_CODESEPARATOR will not delete scriptCode( lastOP_CODESEPARATOR will be deleted after every script);
  • SINGLE does not commit input index.When ANYONECANPAY has no setting,the meaning will not be changed,hashPrevouts and outpoint are implicit committed in input index. When SINGLE use ANYONECANPAY, signed input and output will exist in pairs, but have no limitation to index.
2.BIP143 Signature
In go language, we use btcsuite database to finish signature, btcsuite database is an integrated Bitcoin database, it can generate all nodes program of Bitcoin, but we just use btcsuite database public key/private key API, SHA API and sign RFC6979 signature API. In order to avoid redundancy, the following codes have no adjustments to codes.
2.1
Transaction HASH generation
Transaction information hash generation, every input in transaction will generate a hash value, if there are multi-input in the transaction, then a hash array will be generated, every hash in the array will be consistent with input in transaction.
https://preview.redd.it/n0x5bo9cl7b11.png?width=629&format=png&auto=webp&s=63f4951e5ca7d0cffc6e8905f5d4b33354aa6ecc
Like two transaction input in the image above, every transaction will generate a hash, the transaction above will generate two hash.
  • Fhash function
CalcSignatureHash(script []byte, hashType SigHashType, tx *EMsgTx, idx int)
Explanation:
Script,pubscript is input utxo unlocked script
HashType,signature method or signature type
Tx,details of transaction
Idx,Number of transaction, that is to calculate which transaction hash
The following is Fhash code
https://preview.redd.it/e8xx974gl7b11.png?width=506&format=png&auto=webp&s=9a4f419069bea2e76b8d5b7205a31e06692f3f67
For the situation that multi UTXO input in one transaction, for every input, you can deploy it as examples above, then generate a hash array. Before hash generation, you need to clear “SigantureScript”in other inputs, only leave the “SigantureScript” in this input,That is “ScriptSig”field.
https://preview.redd.it/0omhp2ahl7b11.png?width=462&format=png&auto=webp&s=4cee9b0e4fe10185a39d68bde1032ac4e4dbb9ad
The amount for every UTXO is different. You need to pay attention to the 6th step, what you need to input is the amount for every transaction
Multi-input function generation
func txHash(tx msgtx) ( *[][]byte)
Code details
https://preview.redd.it/rlnxv3lil7b11.png?width=581&format=png&auto=webp&s=804adbee92a9bb9811a4ffc395601ebf191fd664
Repeat deploy Fhash function(CalcSignatureHash)then you can generate a hash array.
2.2Sign with HASH
A hash array is generated in the methods above, for every input with a unique hash in the data, we use signRFC6979 signature function to sign the hash, here we deploy functions in btcsuite database directly.
signRFC6979(PrivateKey, hash)
Through this function, we can generate SigantureScript,add this value to every input SigantureScript field in the transaction.
2.3Multisig
Briefly, multi-sig technology is the question that one UTXO should be signed with how many private keys. There is one condition in script, N public keys are recorded in script, at least M public keys must provide signature to unlock the asset. That is also called M-N method, N is the amount of private keys, M is the signature amount needed for verification
The following is how to realize a 2-2 multisig based on P2SH(Pay-to-Script-Hash) script with go language.
2-2 codes of script function generation:
https://preview.redd.it/7dq7cv9kl7b11.png?width=582&format=png&auto=webp&s=108c6278d656e5fa6b51b5876d5a0f7a1231f933
The function above generated script in the following
2 2 OP_C HECKMULTISIG
Signature function
1. Based on transaction TX,it includes input array []TxIn,generate transaction HASH array,this process is the same as process in general transaction above, deploy the digest function of general transaction above.
func txHash(tx msgtx) ( *[][]byte)
this function generated a hash array, that is every transaction input is consistent with one hash value.
2. Use first public key in redeem script, sign with consistent private key. The process is as general transaction.
signRFC6979(PrivateKey, hash)
After signature, the signature array SignatureScriptArr1 with every single input is generated. Based on this signature value in the array, you can update every input TxIn "SigantureScript" field in transaction TX.
3.Based on updated TX deploy txHash function again, generate new hash array.
func txHash(tx msgtx) ( *[][]byte)
4. Use second public key in redeem script, the consistent private key is used for signature. Use the updated TX in the process above, generate every input hash and sign it.
signRFC6979(PrivateKey, hash)
//Combine the signature generated by first key, signature generated by secondkey and redeem script.
etxscript.EncodeSigScript(&(TX.TxIn[i].SignatureScript),&SigHash2, pkScript)
There are N transactions, so repeat it N times.
The final data is as following:
https://preview.redd.it/78aabhqll7b11.png?width=558&format=png&auto=webp&s=453f7129b2cf3c648b68c2369a4622963087d0c8
References
https://en.wikipedia.org/wiki/Digital_signature*
https://github.com/bitcoin/bips/blob/mastebip-0143.mediawiki
《OReilly.Mastering.Bitcoin.2nd.Edition》
http://www.8btc.com/rfc6979
submitted by StephenCuuuurry to SCRYDDD [link] [comments]

Bitcoin Password hashing program I created.

Hey Guys,
I have seen a lot of comments about how people are getting their Bitcoin wallets passwords violated, and so I was trying to think of how to limit this and came up with a small hashing program that I wrote in Python. It lets you enter in your password and it hashes it into either; md5, sha256, sha512, etc. Due to only thinking of this this morning it is very rough, however it works. The exe has to stay in the same folder as is downloaded as it isn't a static compile, yet. Additionally, you can't include special characters as it crashes the program, I shall be fixing that soon. Anyways, that's the end of my rambling, here is the download link; https://mega.co.nz/#!w4RCABxb!JfYR2Q4p-unp07HuznJh-xiIW50eyM97hN32D6YLHxk
and you can ask me any questions in here.
If you feel like it is a good program, feel free to donate here; 169iA76RmnatFXmEthT6AEehxMQ9X1ro3L however it is not necessary,
Thanks Matt.
EDIT: Some proof that this isn't a virus:
EDIT 2: Source code of the project.
import hashlib from easygui import * import sys image = "bitcoin.gif" msg = "Bitcoin Password Hasher - Please choose an option." choices = ["Start","Donate","Quit"] reply = buttonbox(msg, image=image, choices=choices) if(reply == "Start"): msg = "Please enter your password you would like hashed\n Just not special characters(at the moment anyways.)" title = "matthew_boyd's hashing program." password = enterbox(msg, title) hash = hashlib.sha256(password).hexdigest() hash1 = hashlib.sha224(password).hexdigest() hash2 = hashlib.md5(password).hexdigest() hash3 = hashlib.sha1(password).hexdigest() hash4 = hashlib.sha384(password).hexdigest() hash5 = hashlib.sha512(password).hexdigest() textbox(msg='The hash of your password is written below. Press control + c to copy it. ', title=" Matthew's Hashing program", text="SHA256: " + hash + "\n" + "\n" + "SHA224: " + hash1 + "\n" + "\n" + "MD5: " + hash2 + "\n" + "\n" + "SHA1: " + hash3 + "\n" + "\n" + "SHA384: " + hash4 + "\n" + "\n" + "SHA512: " + hash5, codebox=0) elif(reply == "Donate"): textbox(msg="Donation Address", title="Matthew's Hashing Program", text="Bitcoin donation address: 169iA76RmnatFXmEthT6AEehxMQ9X1ro3L", codebox=0) else: sys.exit() 
submitted by matthew_boyd to Bitcoin [link] [comments]

Hasher and encoder in only 32 lines of code, well spaced.

import hashlib from easygui import * import sys import time from pyDes import * image = "bitcoin.gif" msg = "Bitcoin Password Hasher - Please choose an option." choices = ["Start","Donate","Quit"] reply = buttonbox(msg, image=image, choices=choices) if(reply == "Start"): msg = "Please enter your password you would like hashed\n Just not special characters(at the moment anyways.)" title = "matthew_boyd's hashing program." password = enterbox(msg, title) hash = hashlib.sha256(password).hexdigest() hash1 = hashlib.sha224(password).hexdigest() hash2 = hashlib.md5(password).hexdigest() hash3 = hashlib.sha1(password).hexdigest() hash4 = hashlib.sha384(password).hexdigest() hash5 = hashlib.sha512(password).hexdigest() textbox(msg='The hash of your password is written below. Press control + c to copy it. ', title=" Matthew's Hashing program", text="SHA256: " + hash + "\n" + "\n" + "SHA224: " + hash1 + "\n" + "\n" + "MD5: " + hash2 + "\n" + "\n" + "SHA1: " + hash3 + "\n" + "\n" + "SHA384: " + hash4 + "\n" + "\n" + "SHA512: " + hash5, codebox=0) msg = "please enter the hash you want encrypted" title = "matthew_boyd's hashing program." encryption = enterbox(msg, title) var = des("DESCRYPT", CBC, "\0\0\0\0\0\0\0\0", pad=None, padmode=PAD_PKCS5) var1 = var.encrypt(encryption) textbox(msg='The hash encrypted, make sure to Control + C to copy it.', title=" Matthew's Hashing program", text="Encrypted: %r" % var1 + "\n" + "\n" + "Decrypted: %r" % var.decrypt(var1) + "\n" + "\n") elif(reply == "Donate"): textbox(msg="Donation Address", title="Matthew's Hashing Program", text="Bitcoin donation address: 169iA76RmnatFXmEthT6AEehxMQ9X1ro3L", codebox=0) else: sys.exit() 
Edit: I know that I am not a good coder in any respect. This was literally about my first project that I was somewhat happy with, even though everything is done via modules.
I just compiled it using Py2Exe.
Hope it comes in useful to some of you! ;) Thanks, Matt.
submitted by matthew_boyd to tinycode [link] [comments]

Best Bitcoin (BTC) Indicators To Use On Tradingview! - YouTube BITCOIN PREIS & DIE HASH RATE SINKEN - WARUM DU DENNOCH INVESTIEREN SOLLTEST KOLLABIERT BITCOIN NUN AUFGRUND DER HASH RIBBON? J'AI REÇU MA MACHINE DE BITCOIN ! feat. Hasheur - YouTube O que é um hash? (bitcoin / blockchain) - YouTube

Ein Hash-Algorithmus wandelt Daten beliebiger Länge in einen Datensatz fester Länge um, den Hash. Gleiche Daten führen immer zum gleichen Hash. Wird aber auch nur ein einzelnes Bit der Daten geändert sieht der Hash komplett anders aus. Wie alle Daten im Computer bestehen Hashes aus langen Zahlenketten und werden für gewöhnlich in hexadezimaler Schreibweise angegeben. Bitcoin benutzt den ... Beispiele für Hash Funktionen wären zum Beispiel der bereits genannte SHA-256, der auch von Bitcoin verwendet wird. SHA-256 gehört zu der Gruppe von SHA-2 Algorithmen, entwickelt vom National Institute of Standards and Technology. SHA-256d wird von der Peercoin und Namecoin verwendet. Das Bitcoin-System verlangt nun, dass dieser Hash kleiner als ein vorgegebener Zielwert sein muss. Dadurch wird die Aufgabe, einen gültigen Hash zu finden, schwierig: Kryptografische Hash ... Bitcoin Merkle Baum . Hash-Bäume können verwendet werden, um jede Art von Daten, die in und zwischen Computern gespeichert, verarbeitet und übertragen werden, zu überprüfen. Gegenwärtig wird Hash-Bäumen hauptsächlich verwendet, um sicherzustellen, dass Datenblöcke, die von anderen Peers in einem Peer-to-Peer-Netzwerk empfangen werden, unbeschädigt und unverändert empfangen werden ... Buying Hash-power. Rent out massive hash-power on the largest and most advanced hash-power marketplace. We support a wide range of pools! Start buying. learn more. Cryptocurrency Exchange. Exchange fiat to crypto or just crypto to crypto. Use our live trading interface with advanced trading options and API. Start trading . learn more. READ NEWS NiceHash Latest News. guides & tutorials. 23 Oct ...

[index] [35514] [8853] [23696] [39310] [27353] [42801] [9332] [4035] [30035] [20720]

Best Bitcoin (BTC) Indicators To Use On Tradingview! - YouTube

Bienvenue sur ma chaîne ! Je me présente, Owen Simonin (alias Hasheur), je vulgarise sur Youtube différentes technologies, techniques et stratégies complexes... Over the years I've learned the best indicators to use on Tradingview based on my style of trading for Bitcoin. I like to use multiple indicators for confirm... Learn how to Brute-Force your Bitcoin core wallet using Hashcat. Get the Bitcoin2John.py script here: https://github.com/magnumripper/JohnTheRipper/blob/blee... Im heutigen Video sprechen wir über die Frage, warum Investoren Angst haben in den Bitcoin zu investieren. Außerdem sehen wir uns an warum die Hash Rate um 30% gesunken ist und warum der Bitcoin ... Im heutigen Video sprechen wir über die Gründe, warum der Bitcoin kollabieren könnte aufgrund der Hash Ribbon. Außerdem sehen wir uns an warum das Transaktionsvolumen gesunken ist und wie ...

#