Pubkey To Address - Bitcoin Tools

Why does BIP-199 promote the usage of pubkey hashes (instead of addresses)? /r/Bitcoin

Why does BIP-199 promote the usage of pubkey hashes (instead of addresses)? /Bitcoin submitted by cryptoanalyticabot to cryptoall [link] [comments]

Why does BIP-199 promote the usage of pubkey hashes (instead of addresses)? /r/Bitcoin

Why does BIP-199 promote the usage of pubkey hashes (instead of addresses)? /Bitcoin submitted by ABitcoinAllBot to BitcoinAll [link] [comments]

Multisig with hashes instead of pubkeys | Andrew | Dec 22 2016 /r/bitcoin_devlist

Multisig with hashes instead of pubkeys | Andrew | Dec 22 2016 /bitcoin_devlist submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Pay-to-pubkey-hash with sighash_none /r/Bitcoin

Pay-to-pubkey-hash with sighash_none /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Pay-to-Pubkey Hash /r/Bitcoin

Pay-to-Pubkey Hash /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

When will quantum break crypto?

Today, there was a new article that sprung up about how D Wave now has the first commercial quantum computer for businesses with 5,000 qubits. How large of a quantum computer would be needed to bust into people’s wallets? How close are we to that happening?
submitted by the-ace-of-space to Bitcoin [link] [comments]

Fun with OP_HODL (CheckLockTimeVerify)

Finally got around to messing around with python-bitcoinlib, and I'm very impressed. Great work by Peter Todd. I went ahead and cooked up a sample based off of the ones provided to test OP_HODL. This is bitcoin contract that can lock funds in a UTXO until a specified time has arrived.
This script will lock funds in a UTXO until "10/13/2020 @ 6:55am (UTC)". Though realistically you really need to wait about an hour past your expiry time since the nLockTime logic uses that average of the last 11 blocks as a clock, not the last block.
Here's a breakdown:
First look at the witness program on the spending txn.

If we add the deserialize the witnessScript this is what we get:
< OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG>
Looking at the 2nd output of the funding txn, you should see the ScriptPubKey is simply OP_0 to signal segwit and the hash of the witness script.
OP_0
And of course, our nLockTime in our spending TXN matches our expiry, and our sequence in our spending txn is encoded to allow nLockTime processing.
One thing that was interesting with nLockTime txns is that they are completely invalid before they "ripen". You can't even store them in your wallet. You just have to wait to broadcast until the right time transpires. Broadcasting early will fail with a non-final error.
The CoinBin wallet is the only one I know of that allows you to create OP_HODL addresses, but I'm not certain they provide a way to spend them.
submitted by brianddk to Bitcoin [link] [comments]

Technical: Taproot: Why Activate?

This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/
Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else wants it, but why would I, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else because I swapped XXX fiat for Bitcoin unlike all those nocoiners?
And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess.
First, let's consider some principles of Bitcoin.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can get privacy, it just requires effort to do so).
So, how does Taproot affect those principles?

Taproot and Your /Coins

Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash).
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input).
However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits!
Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh?
With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save!
And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a softfork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well!
(P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1)
Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least 2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service!
So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win!
(even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot)
And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally. First do no harm!

Taproot and Your Contracts

No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade.
So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust.
Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade.
However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade.
In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address.
Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants).
But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer).
Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables more of these setups to happen for more gains from trade for everyone, also, moon and lambos).
(technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).

Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code.
This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded.
And you can do that, with HTLCs, today.
Of course, HTLCs do have problems:
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar".
Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given public key to you.
Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige).
(Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key).
So:
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script.
(technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)

Quantum Quibbles!

Now if you were really paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable??
Well, in theory yes. In practice, they probably are not.
It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P2WPKH/P2PKH pay-to-public-key-hash.
When you spend from a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key.
So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key.
(public keys should be public, that's why they're called public keys, LOL)
And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions.
So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort.
Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers.
For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
So:
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).

Summary

I Wanna Be The Taprooter!

So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do!

But I Hate Taproot!!

That's fine!

Discussions About Taproot Activation

submitted by almkglor to Bitcoin [link] [comments]

Tron v11.1.3 (2020-08-20) // Minor updates; Remove PCHunter due to A/V false positives

Background

Tron is a script that "fights for the User."
It aims to automate ~87% of the tedious work in getting a badly-running Windows system back on its feet (clicking "next" in a/v scan windows, etc); with much left to the discretion of the tech.
It is built with heavy reliance on community input and updated regularly.
It is NOT a system optimization or "baseline" script.
Read the instructions.

Sequence of operation

Prep > Tempclean > De-bloat > Disinfect > Repair > Patch > Optimize > Wrap-up | Manual tools
Saves a log to C:\logs\tron\tron.log (configurable).
screenshots of Tron in action

Changelog

(significant changes in bold; full changelog on Github)
v11.1.3 (2020-08-20)
- Removed PCHunter utility (extra utility, Tron never ran PCHunter) due to false positives with many A/V engines
. Minor definition updates

Download

  1. Primary method: Download the .torrent.
  2. Secondary: Download a self-extracting .exe pack from one of the mirrors:
    Mirror HTTPS HTTP Location Host
    Official link link US-DC u/SGC-Hosting
    #1 link link US-NY u/danodemano
    #3 link link DE u/bodrino
    #4 link link US/EU u/mxmod
    #5 link --- US-MI u/ajcutshall
    #6 link --- AU u/agent-squirrel
    #7 link --- GB-LND u/FreezerMoosh
    #8 link --- US-MO u/OlderGeeks
    #9 link --- Amazon CDN u/helpdesktv
    #10 link --- Global CDN Softpedia
  3. Tertiary: Connect to the Syncthing repo (instructions) to get fixes/updates immediately. This method has some risks and you should only use it if you understand them.
  4. Quaternary: Source code
    Source code is available on Github (Note: this doesn't include many of the utilities Tron relies on to function). If you want to view the code without downloading a ~600MB package, Github is a good place to do it.

Command-Line Support

Tron has full command-line support. Switches are optional, can be used simultaneously, and override their respective default when used. See here for a list of command-line switches.

Pack Integrity

SHA-256 hashes are in \tron\integrity_verification\checksums.txt and are signed with my PGP key; included. Use this to verify pack integrity.

Donations

Tron will always be free and open-source. If you'd like to buy me a beer or more importantly ... scotch ... you can do so here:
  • Patreon
  • Bitcoin: 1Biw8gx2kD7mZf66ZdNgB9tG1pE9YA3kEd
  • Bitcoin Cash: 18sXTTrAViPZVQtm63zBK6aCK3XfJpEThk
  • Monero (preferred): 4GG9KsJhwcW3zapDw62UaS71ZfFBjH9uwhc8FeyocPhUHHsuxj5zfvpZpZcZFHWpxoXD99MVt6PnR9QfftXDV8s6HbYdDuZEDZ947uiEje
These addresses go directly to u/vocatus. If you wish to support another volunteer (e.g. the incredibly generous u/SGC-Hosting) please contact them directly.

Problems and Support

Please look here first for a list of common issues (Tron appearing to be stalled, etc). If it doesn't answer your issue, make a top-level post to TronScript and myself or one of the community members will look at the issue. Additionally, you can reach me 24/7 on Keybase.
\integrity verification contains checksums.txt and is signed with my PGP key (0x07d1490f82a211a2, pubkey included). Use this to verify the pack.
"Do not withhold good from those to whom it is due, when it is in your power to act." -p3:27
submitted by vocatus to TronScript [link] [comments]

Weird behavior when scripting electrum's ECPrivkey(...).sign_transaction(...)

Update

Nevermind... Electrum is performing low-value R-grinding and bitcoinlib and CoinBin are not. For anyone interested, the grinding code his here. Nuking the while look makes the sigs the same.
A few days ago I used bitcoinlib to create a OP_CLTV transaction. Tonight I did the same with Electrum 4.0.4 via python and my sigs don't match.
The TXN I'm trying to match is:
The TXN has the following characteristics:
When I try signing the sighash (pre-image hash) using both bitcoinlib and Electrum 4.0.4, I get different results. I coded the TXN through another wallet as well (CoinBin), and bitcoinlib seems to be producing the proper signature, but Electrum's seems off.
I'm sure there is something simple I'm missing, but I can't figure it out.
Here's a test script to illustrate the differences:
``` from bitcoin.core.key import use_libsecp256k1_for_signing from bitcoin.core import x, b2x from bitcoin.wallet import CBitcoinSecret from electrum.ecc import ECPrivkey from electrum.bitcoin import EncodeBase58Check
use_libsecp256k1_for_signing(True) sechex = '535b755a4c265772c4f6c7e0316bfd21e24c9e47441989e14e8133c7cb2f41a3' hashhex = '9039c54c1c34aa12b69b4dda962f501bb6c9cdb6745014ef326f5d4d0472aa99' seckey = CBitcoinSecret.from_secret_bytes(x(sechex)) sig = seckey.sign(x(hashhex)) b_wif = str(seckey) b_pub = b2x(seckey.pub) b_sig = b2x(sig) seckey = ECPrivkey(x(sechex)) sig = seckey.sign_transaction(x(hashhex)) e_wif = EncodeBase58Check(b'\x80' + seckey.get_secret_bytes() + b'\x01') e_pub = seckey.get_public_key_hex(compressed=True) e_sig = b2x(sig) assert b_wif == e_wif assert b_pub == e_pub print("wif:", b_wif) print("pub:", b_pub) print("sighash:", hashhex) print("bitcoinlib sig:", b_sig) print("electrum sig: ", e_sig) 
```
The resultant sigs are:
Thoughts?
submitted by brianddk to Electrum [link] [comments]

Tron v11.1.2 (2020-07-13) // Fix screen rotation bug caused by O&OSU10; escape some references to %USERNAME%; minor definition updates

Background

Tron is a script that "fights for the User."
It aims to automate ~87% of the tedious work in getting a badly-running Windows system back on its feet (clicking "next" in a/v scan windows, etc); with much left to the discretion of the tech.
It is built with heavy reliance on community input and updated regularly.
It is NOT a system optimization or "baseline" script.
Read the instructions.

Sequence of operation

Prep > Tempclean > De-bloat > Disinfect > Repair > Patch > Optimize > Wrap-up | Manual tools
Saves a log to C:\logs\tron\tron.log (configurable).
screenshots of Tron in action

Changelog

(significant changes in bold; full changelog on Github)
v11.1.2 (2020-07-13)
! bugfix: Wrap missed reference to %TEMP% in quotes. Thanks to u/TheDarkThought
- Minor definition updates

Download

  1. Primary method: Download the .torrent.
  2. Secondary: Download a self-extracting .exe pack from one of the mirrors:
    Mirror HTTPS HTTP Location Host
    Official link link US-DC u/SGC-Hosting
    #1 link link US-NY u/danodemano
    #3 link link DE u/bodrino
    #4 link link US/EU u/mxmod
    #5 link --- US-MI u/ajcutshall
    #6 link --- AU u/agent-squirrel
    #7 link --- GB-LND u/FreezerMoosh
    #8 link --- US-MO u/OlderGeeks
    #9 link --- Amazon CDN u/helpdesktv
    #10 link --- Global CDN Softpedia
  3. Tertiary: Connect to the Syncthing repo (instructions) to get fixes/updates immediately. This method has some risks and you should only use it if you understand them.
  4. Quaternary: Source code
    Source code is available on Github (Note: this doesn't include many of the utilities Tron relies on to function). If you want to view the code without downloading a ~600MB package, Github is a good place to do it.

Command-Line Support

Tron has full command-line support. Switches are optional, can be used simultaneously, and override their respective default when used. See here for a list of command-line switches.

Pack Integrity

SHA-256 hashes are in \tron\integrity_verification\checksums.txt and are signed with my PGP key; included. Use this to verify pack integrity.

Donations

Tron will always be free and open-source. If you'd like to buy me a beer or more importantly ... scotch ... you can do so here:
  • Patreon
  • Bitcoin: 1Biw8gx2kD7mZf66ZdNgB9tG1pE9YA3kEd
  • Bitcoin Cash: 18sXTTrAViPZVQtm63zBK6aCK3XfJpEThk
  • Monero (preferred): 4GG9KsJhwcW3zapDw62UaS71ZfFBjH9uwhc8FeyocPhUHHsuxj5zfvpZpZcZFHWpxoXD99MVt6PnR9QfftXDV8s6HbYdDuZEDZ947uiEje
These addresses go directly to u/vocatus. If you wish to support another volunteer (e.g. the incredibly generous u/SGC-Hosting) please contact them directly.

Problems and Support

Please look here first for a list of common issues (Tron appearing to be stalled, etc). If it doesn't answer your issue, make a top-level post to TronScript and myself or one of the community members will look at the issue. Additionally, you can reach me 24/7 on Keybase.
\integrity verification contains checksums.txt and is signed with my PGP key (0x07d1490f82a211a2, pubkey included). Use this to verify the pack.
"Do not withhold good from those to whom it is due, when it is in your power to act." -p3:27
submitted by vocatus to TronScript [link] [comments]

[ Bitcoin ] Technical: Taproot: Why Activate?

Topic originally posted in Bitcoin by almkglor [link]
This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/
Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else wants it, but why would I, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else because I swapped XXX fiat for Bitcoin unlike all those nocoiners?
And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess.
First, let's consider some principles of Bitcoin.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can get privacy, it just requires effort to do so).
So, how does Taproot affect those principles?

Taproot and Your /Coins

Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash).
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input).
However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits!
Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh?
With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save!
And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a softfork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well!
(P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1)
Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least 2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service!
So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win!
(even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot)
And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally. First do no harm!

Taproot and Your Contracts

No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade.
So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust.
Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade.
However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade.
In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address.
Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants).
But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer).
Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables more of these setups to happen for more gains from trade for everyone, also, moon and lambos).
(technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).

Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code.
This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded.
And you can do that, with HTLCs, today.
Of course, HTLCs do have problems:
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar".
Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given private key to you.
Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige).
(Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key).
So:
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script.
(technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)

Quantum Quibbles!

Now if you were really paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable??
Well, in theory yes. In practice, they probably are not.
It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P2WPKH/P2PKH pay-to-public-key-hash.
When you spend from a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key.
So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key.
(public keys should be public, that's why they're called public keys, LOL)
And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions.
So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort.
Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers.
For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
So:
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).

Summary

I Wanna Be The Taprooter!

So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do!

But I Hate Taproot!!

That's fine!

Discussions About Taproot Activation

almkglor your post has been copied because one or more comments in this topic have been removed. This copy will preserve unmoderated topic. If you would like to opt-out, please send a message using [this link].
[deleted comment]
[deleted comment]
[deleted comment]
submitted by anticensor_bot to u/anticensor_bot [link] [comments]

Bitcoin Desmitificado Parte - 3

La banca y el acceso a ella
A diferencia de la banca actual en la que existe una estructura administrativa o corporativa en la red Bitcoin no existe una estructura cómo está, ya que las decisiones son automatizadas y preprogramadas. Ninguna entidad es la encargada de mantener el libro mayor y nos registros que se encuentran no pueden ser modificados sin que los demás miembros de la red lo detecten.
Bitcoin opera fuera del sistema financiero tradicional, el valor está en función de la oferta y la demanda, hasta el momento hay poca o nula interferencia de los gobiernos, no hay leyes arbitrarias que seguir para poder entrar en este mercado y es un sistema impulsado por el usuarios, con la ventaja de poder ocultar las tenencias al estado y administrar las transacciones financieras cómo lo desee.
Bitcoin viene a ser una alternativa para los séis billones y medio de personas en el planeta que carecen de acceso a algún tipo de sistema monetario y que quieren entrar al cocomercio con alcance mundial. Crear una cuenta es sencillo y solo se requiere que tenga un monto mínimo que se puede hacer desde un dólar, incluso existen sitios web que dan pequeñas cantidades de Bitcoins a las personas que desean probar la moneda. Es tan sencillo participar en la red en comparativa con el sistema financiero en los cuales se debe aprobar los préstamos para poder hacer uso de la tarjeta de crédito. El único requisito para poder hacer transacciones en la red es el acceso a Internet y contar con fondo, de esta manera se podrían realizar pagos con comisiones menores a las que brinda los bancos.
Privacidad en la red BTC
Bitcoin utiliza un libro de contabilidad público que indica la cantidad de bitcoins y las direcciones a las que pertenecen. Un ejemplo de una dirección Bitcoin utiliza Pubkey hash (P2PKH address) 17VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem, en la dirección no se especifica nombre del usuario o empresa a la que pertenece, es por esta razón que se pueden utilizar las direcciones sin revelar la identidad, la única manera que se pueden asociar una dirección a una entidad, es que la entidad lo publique, por ejemplo una ONG que publique la dirección para recibir donaciones.
Bitcoin representa una forma casi perfecta de realizar diversas transacciones financieras sin que se rastree o almacene información personal. Las transacciones realizadas en BItcoins son tan distintas a las transacciones que se realizan con las tarjetas de crédito ya que en la banca tradicional es necesario que el banco actualice su libro de contabilidad privado en el que se encuentra las cuentas a las cuales se aplicará la transacción.
Pero al ser este libro mayor privado la información de quién es el propietario de la cuenta se puede perder por algún caso fortuito, este escenario no ocurre ya que cuenta el banco cuenta con respaldo de datos, pero a diferencia de Bitcoin, existen copias idénticas del libro mayor en todos los equipos de la red de esta manera se evita un punto central de falla, y cada transacción realizada será permanente e imposible de borrar ya que todos los equipos actualizan la lista de transacciones. Realizar una transacción es equivalente a ejecutar una instrucción en todas las computadoras de la red, esto permite que todo tenga la misma información.
Conclusiones
Bitcoin al ser una moneda relativamente nueva y que ha presentado ser seguro por los métodos de encriptación que utiliza es recomendable esperar que se convierta en una moneda confiable en todos los países, sólo así podría reemplazar las transacciones financieras actuales. Ya que por el momento los dueños de Bitcoins al no ser respaldados por un metal se puede dar el caso de perder lo invertido.
Se deben tener regulaciones para la protección al consumidor. Cómo ya fue mencionado cada transacción realizada es irreversible, el objetivo de regular sería para evitar que se realicen transacciones fraudulentas y brindarle la seguridad al consumidor de que el riesgo de pagar con Bitcoin no es diferente al de pagar con la tarjeta de crédito.
Se debe esperar que más comerciantes aceptan cómo moneda de pago los Bitcoins, esperar que se instalen dispositivos en la tiendas como los pagos utilizando la tecnología NFC, de esta manera considero que tomaría mayor popularidad cómo la que tiene PayPal.
submitted by calogero401 to u/calogero401 [link] [comments]

Tron v11.1.0 (2020-04-25) // Remove Malwarebytes installation by default (-pmb to preserve); French language fix; definition and de-bloat updates

Background

Tron is a script that "fights for the User."
It aims to automate ~87% of the tedious work in getting a badly-running Windows system back on its feet (clicking "next" in a/v scan windows, etc); with much left to the discretion of the tech.
It is built with heavy reliance on community input and updated regularly.
It is NOT a system optimization or "baseline" script.
Read the instructions.

Sequence of operation

Prep > Tempclean > De-bloat > Disinfect > Repair > Patch > Optimize > Wrap-up | Manual tools
Saves a log to C:\logs\tron\tron.log (configurable).
screenshots of Tron in action

Changelog

(significant changes in bold; full changelog on Github)
v11.1.0 (2020-04-25)
/ Change REMOVE_MALWAREBYTES to PRESERVE_MALWAREBYTES (-pmb) as the new default behavior is to remove it at the end of the script
* Fix for Internet connection check on French language systems
* Minor definition updates for sub-tools and A/V engines

Download

  1. Primary method: Download the .torrent.
  2. Secondary: Download a self-extracting .exe pack from one of the mirrors:
    Mirror HTTPS HTTP Location Host
    Official link link US-DC u/SGC-Hosting
    #1 link link US-NY u/danodemano
    #3 link link DE u/bodrino
    #4 link link US/EU u/mxmod
    #5 link --- US-MI u/ajcutshall
    #6 link --- AU u/agent-squirrel
    #7 link --- GB-LND u/FreezerMoosh
    #8 link --- US-MO u/OlderGeeks
    #9 link --- Amazon CDN u/helpdesktv
    #10 link --- Global CDN Softpedia
  3. Tertiary: Connect to the Syncthing repo (instructions) to get fixes/updates immediately. This method has some risks and you should only use it if you understand them.
  4. Quaternary: Source code
    Source code is available on Github (Note: this doesn't include many of the utilities Tron relies on to function). If you want to view the code without downloading a ~600MB package, Github is a good place to do it.

Command-Line Support

Tron has full command-line support. Switches are optional, can be used simultaneously, and override their respective default when used. See here for a list of command-line switches.

Pack Integrity

SHA-256 hashes are in \tron\integrity_verification\checksums.txt and are signed with my PGP key; included. Use this to verify pack integrity.

Donations

Tron will always be free and open-source. If you'd like to buy me a beer or more importantly ... scotch ... you can do so here:
  • Patreon
  • Bitcoin: 1Biw8gx2kD7mZf66ZdNgB9tG1pE9YA3kEd
  • Bitcoin Cash: 18sXTTrAViPZVQtm63zBK6aCK3XfJpEThk
  • Monero (preferred): 4GG9KsJhwcW3zapDw62UaS71ZfFBjH9uwhc8FeyocPhUHHsuxj5zfvpZpZcZFHWpxoXD99MVt6PnR9QfftXDV8s6HbYdDuZEDZ947uiEje
These addresses go directly to u/vocatus. If you wish to support another volunteer (e.g. the incredibly generous u/SGC-Hosting) please contact them directly.

Problems and Support

Please look here first for a list of common issues (Tron appearing to be stalled, etc). If it doesn't answer your issue, make a top-level post to TronScript and myself or one of the community members will look at the issue. Additionally, you can reach me 24/7 on Keybase.
\integrity verification contains checksums.txt and is signed with my PGP key (0x07d1490f82a211a2, pubkey included). Use this to verify the pack.
"Do not withhold good from those to whom it is due, when it is in your power to act." -p3:27
submitted by vocatus to TronScript [link] [comments]

Tron v11.1.1 (2020-05-25) // Fix -pmb switch behavior; remove deprecated telemetry-removal tasks; prevent CCleaner from wiping Taskbar Jump Lists

Background

Tron is a script that "fights for the User."
It aims to automate ~87% of the tedious work in getting a badly-running Windows system back on its feet (clicking "next" in a/v scan windows, etc); with much left to the discretion of the tech.
It is built with heavy reliance on community input and updated regularly.
It is NOT a system optimization or "baseline" script.
Read the instructions.

Sequence of operation

Prep > Tempclean > De-bloat > Disinfect > Repair > Patch > Optimize > Wrap-up | Manual tools
Saves a log to C:\logs\tron\tron.log (configurable).
screenshots of Tron in action

Changelog

(significant changes in bold; full changelog on Github)
v11.1.1 (2020-05-25)
! Fix -pmb switch behavior
* CCleaner: Disable clearing of Taskbar Jump Lists. Thanks to u/D00shene
- Telemetry removal: Remove outdated job that used to uninstall "bad" updates
- Remove post-run restore point creation

Download

  1. Primary method: Download the .torrent.
  2. Secondary: Download a self-extracting .exe pack from one of the mirrors:
    Mirror HTTPS HTTP Location Host
    Official link link US-DC u/SGC-Hosting
    #1 link link US-NY u/danodemano
    #3 link link DE u/bodrino
    #4 link link US/EU u/mxmod
    #5 link --- US-MI u/ajcutshall
    #6 link --- AU u/agent-squirrel
    #7 link --- GB-LND u/FreezerMoosh
    #8 link --- US-MO u/OlderGeeks
    #9 link --- Amazon CDN u/helpdesktv
    #10 link --- Global CDN Softpedia
  3. Tertiary: Connect to the Syncthing repo (instructions) to get fixes/updates immediately. This method has some risks and you should only use it if you understand them.
  4. Quaternary: Source code
    Source code is available on Github (Note: this doesn't include many of the utilities Tron relies on to function). If you want to view the code without downloading a ~600MB package, Github is a good place to do it.

Command-Line Support

Tron has full command-line support. Switches are optional, can be used simultaneously, and override their respective default when used. See here for a list of command-line switches.

Pack Integrity

SHA-256 hashes are in \tron\integrity_verification\checksums.txt and are signed with my PGP key; included. Use this to verify pack integrity.

Donations

Tron will always be free and open-source. If you'd like to buy me a beer or more importantly ... scotch ... you can do so here:
  • Patreon
  • Bitcoin: 1Biw8gx2kD7mZf66ZdNgB9tG1pE9YA3kEd
  • Bitcoin Cash: 18sXTTrAViPZVQtm63zBK6aCK3XfJpEThk
  • Monero (preferred): 4GG9KsJhwcW3zapDw62UaS71ZfFBjH9uwhc8FeyocPhUHHsuxj5zfvpZpZcZFHWpxoXD99MVt6PnR9QfftXDV8s6HbYdDuZEDZ947uiEje
These addresses go directly to u/vocatus. If you wish to support another volunteer (e.g. the incredibly generous u/SGC-Hosting) please contact them directly.

Problems and Support

Please look here first for a list of common issues (Tron appearing to be stalled, etc). If it doesn't answer your issue, make a top-level post to TronScript and myself or one of the community members will look at the issue. Additionally, you can reach me 24/7 on Keybase.
\integrity verification contains checksums.txt and is signed with my PGP key (0x07d1490f82a211a2, pubkey included). Use this to verify the pack.
"Do not withhold good from those to whom it is due, when it is in your power to act." -p3:27
submitted by vocatus to TronScript [link] [comments]

Tron v11.0.1 (2020-03-31) // Ultra Mega Coronavirus Edition; minor definition updates

Background

Tron is a script that "fights for the User."
It aims to automate ~87% of the tedious work in getting a badly-running Windows system back on its feet (clicking "next" in a/v scan windows, etc); with much left to the discretion of the tech.
It is built with heavy reliance on community input and updated regularly.
It is NOT a system optimization or "baseline" script.
Read the instructions.

Sequence of operation

Prep > Tempclean > De-bloat > Disinfect > Repair > Patch > Optimize > Wrap-up | Manual tools
Saves a log to C:\logs\tron\tron.log (configurable).
screenshots of Tron in action

Changelog

(significant changes in bold; full changelog on Github)
v11.0.1 (2020-03-31)
* Minor definition updates for sub-tools and A/V engines
v11.0.0 (2020-02-05)
+ Add switch REMOVE_MALWAREBYTES (-rmb) to have Tron automatically uninstall Malwarebytes at the end of the run
+ Add switch SKIP_COOKIE_CLEANUP (-scc) to have Tron preserve ALL browser cookies. This is NOT generally recommended as Tron now automatically preserves the most common login cookies (chase.com, spotify.com, gmail.com, etc) and wiping other tracking cookies is still good for user privacy and security. You can see the list of cookies Tron preserves in this file. Thanks to tbr:sebastian.
- Remove BleachBit. This is despite the fact that I prefer BleachBit over CCleaner. Reason 1) It performs the same function as CCleaner. Reason 2) It doesn't support excluding certain cookie domains from wiping (the main reason). Once BleachBit supports cookie whitelisting, we will switch over to it exclusively and remove CCleaner from Tron
* Stage 1: Temp file cleanup: Streamline user profile cleanup code, removing a redundant code block
! Stage 5: Patch: Suppress Windows Defender update output unless running in verbose mode
* Update all sub-tools and definition files

Download

  1. Primary method: Download the .torrent.
  2. Secondary: Download a self-extracting .exe pack from one of the mirrors:
    Mirror HTTPS HTTP Location Host
    Official link link US-DC u/SGC-Hosting
    #1 link link US-NY u/danodemano
    #3 link link DE u/bodrino
    #4 link link US/EU u/mxmod
    #5 link --- US-MI u/ajcutshall
    #6 link --- AU u/agent-squirrel
    #7 link --- GB-LND u/FreezerMoosh
    #8 link --- US-MO u/OlderGeeks
    #9 link --- Amazon CDN u/helpdesktv
    #10 link --- Global CDN Softpedia
  3. Tertiary: Connect to the Syncthing repo (instructions) to get fixes/updates immediately. This method has some risks and you should only use it if you understand them.
  4. Quaternary: Source code
    Source code is available on Github (Note: this doesn't include many of the utilities Tron relies on to function). If you want to view the code without downloading a ~600MB package, Github is a good place to do it.

Command-Line Support

Tron has full command-line support. Switches are optional, can be used simultaneously, and override their respective default when used. See here for a list of command-line switches.

Pack Integrity

SHA-256 hashes are in \tron\integrity_verification\checksums.txt and are signed with my PGP key; included. Use this to verify pack integrity.

Donations

Tron will always be free and open-source. If you'd like to buy me a beer or more importantly ... scotch ... you can do so here:
  • Patreon
  • Bitcoin: 1Biw8gx2kD7mZf66ZdNgB9tG1pE9YA3kEd
  • Bitcoin Cash: 18sXTTrAViPZVQtm63zBK6aCK3XfJpEThk
  • Monero (preferred): 4GG9KsJhwcW3zapDw62UaS71ZfFBjH9uwhc8FeyocPhUHHsuxj5zfvpZpZcZFHWpxoXD99MVt6PnR9QfftXDV8s6HbYdDuZEDZ947uiEje
These addresses go directly to u/vocatus. If you wish to support another volunteer (e.g. the incredibly generous u/SGC-Hosting) please contact them directly.

Problems and Support

Please look here first for a list of common issues (Tron appearing to be stalled, etc). If it doesn't answer your issue, make a top-level post to TronScript and myself or one of the community members will look at the issue. Additionally, you can reach me 24/7 on Keybase.
\integrity verification contains checksums.txt and is signed with my PGP key (0x07d1490f82a211a2, pubkey included). Use this to verify the pack.
"Do not withhold good from those to whom it is due, when it is in your power to act." -p3:27
submitted by vocatus to TronScript [link] [comments]

"Did Satoshi really have an bitcoin address?" - how should we treat bare-pubkey P2PK outputs?

What's the genesis address of Bitcoin, which is supposed to belong to Satoshi Nakamoto? 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa right?
I'm afraid to say that some Bitcoin Core devs may disagree with that. Probably they would say that "Satoshi did not really had any 'bitcoin address' at all".
Technically there are indeedly several facts which are really not intuitive:
  1. The 50BTC in the genesis block is not spendable. (this is not really related)
  2. Satoshi used bare-pubkey P2PK outputs, which is not same thing with the currently commonly used P2PKH public key hash outputs, let alone SegWit outputs (both bc1-starting P2WPKH addresses or 3-starting P2SH-P2WPKH addresses require the public key to be hashed).
  3. A lot of "ancient" transactions uses such bare-pubkey outputs, which are also uncompressed public keys. (this is not really related either)
However, quite a few things in the bitcoin ecosystem still recognize P2PK outputs as a thing of the same class with P2PKH, including Bitcoin Core itself.
Then guess what? The latest release (0.20.0) of Bitcoin Core has just removed one of the legacy traces of this issue: Pull request #16725: Don't show addresses or P2PK in decoderawtransaction
However it seems that the GUI wallet still hasn't remove similar logics, so that 1-starting P2PKH addresses could still show up if you create a new wallet and then import some ancient pubkeys into it, just like the screenshot posted here.
Block explorers also behave differently on this issue. Blockstream.info won't show corresponding P2PKH address of bare-pubkey P2PK outputs at all, while Blockchain.info would show the full string of 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa.
In my own opinion probably Bitcoin Core is not doing something correct this time. However it's not good to confuse P2PK with P2PKH either.
submitted by KiFastCallEntry to Bitcoin [link] [comments]

For all those spamming with posts about quantum shit, here is the answer for you: Quantum Badger

For all those spamming with posts about quantum shit, here is the answer for you: Quantum Badger submitted by DarthCoinMaster to Bitcoin [link] [comments]

Tron v11.0.0 (2020-02-05) // Automatically preserve login cookies for common sites (chase.com, gmail.com, etc); Add REMOVE_MALWAREBYTES and SKIP_COOKIE_CLEANUP switches; Improve Windows Disk Cleanup, Remove BleachBit (see notes); streamline user profile cleanup

Background

Tron is a script that "fights for the User." Think of it as a tech on a thumb drive that automates ~87% of the tedious work in cleaning a Windows system, with some things left to the discretion of the tech. It is built with heavy reliance on community input and updated regularly.

Sequence of operation

Prep > Tempclean > De-bloat > Disinfect > Repair > Patch > Optimize > Wrap-up | Manual tools
Saves a log to C:\logs\tron\tron.log (configurable).
screenshots of Tron in action

Changelog

(significant changes in bold; full changelog on Github)
v11.0.0 (2020-02-05)
+ Add switch REMOVE_MALWAREBYTES (-rmb) to have Tron automatically uninstall Malwarebytes at the end of the run
+ Add switch SKIP_COOKIE_CLEANUP (-scc) to have Tron preserve ALL browser cookies. This is NOT generally recommended as Tron now automatically preserves the most common login cookies (chase.com, spotify.com, gmail.com, etc) and wiping other tracking cookies is still good for user privacy and security. You can see the list of cookies Tron preserves in this file. Thanks to tbr:sebastian.
- Remove BleachBit. This is despite the fact that I prefer BleachBit over CCleaner. Reason 1) It performs the same function as CCleaner. Reason 2) It doesn't support excluding certain cookie domains from wiping (the main reason). Once BleachBit supports cookie whitelisting, we will switch over to it exclusively and retire CCleaner from Tron
* Stage 1: Temp file cleanup: Streamline user profile cleanup code, removing a redundant code block
! Stage 5: Patch: Suppress Windows Defender update output unless running in verbose mode
* Update all sub-tools and definition files

Download

  1. Primary method: Download the .torrent.
  2. Secondary: Download a self-extracting .exe pack from one of the mirrors:
    Mirror HTTPS HTTP Location Host
    Official link link US-DC u/SGC-Hosting
    #1 link link US-NY u/danodemano
    #3 link link DE u/bodrino
    #4 link link US/EU u/mxmod
    #5 link --- US-MI u/ajcutshall
    #6 link --- AU u/agent-squirrel
    #7 link --- GB-LND u/FreezerMoosh
    #8 link --- US-MO u/OlderGeeks
    #9 link --- Amazon CDN u/helpdesktv
    #10 link --- Global CDN Softpedia
  3. Tertiary: Connect to the Syncthing repo (instructions) to get fixes/updates immediately. This method has some risks and you should only use it if you understand them.
  4. Quaternary: Source code
    Source code is available on Github (Note: this doesn't include many of the utilities Tron relies on to function). If you want to view the code without downloading a ~600MB package, Github is a good place to do it.

Command-Line Support

Tron has full command-line support. Switches are optional, can be used simultaneously, and override their respective default when used. See here for a list of command-line switches.

Pack Integrity

SHA-256 hashes are in \tron\integrity_verification\checksums.txt and are signed with my PGP key; included. Use this to verify pack integrity.

Donations

Tron will always be free and open-source. If you'd like to buy me a beer or ... more importantly Scotch... you can do so here:
  • Patreon
  • Bitcoin: 1Biw8gx2kD7mZf66ZdNgB9tG1pE9YA3kEd
  • Bitcoin Cash: 18sXTTrAViPZVQtm63zBK6aCK3XfJpEThk
  • Monero (preferred): 4GG9KsJhwcW3zapDw62UaS71ZfFBjH9uwhc8FeyocPhUHHsuxj5zfvpZpZcZFHWpxoXD99MVt6PnR9QfftXDV8s6HbYdDuZEDZ947uiEje
These addresses go directly to u/vocatus. If you wish to support another volunteer (e.g. the incredibly generous u/SGC-Hosting) please contact them directly.

Problems and Support

Please look here first for a list of common issues (Tron appearing to be stalled, etc). If it doesn't answer your issue, make a top-level post to TronScript and myself or one of the community members will look at the issue. Additionally, you can reach me 24/7 on Keybase.
\integrity verification contains checksums.txt and is signed with my PGP key (0x07d1490f82a211a2, pubkey included). Use this to verify the pack.
"Do not withhold good from those to whom it is due, when it is in your power to act." -p3:27
submitted by vocatus to TronScript [link] [comments]

Scripts

What exactly is a bitcoin script??Can anybody explain in detail plus things like pay to keyhash or whatever its called! Its too complicated for a non techie like me
submitted by shivankbatra154 to Bitcoin [link] [comments]

OP_CHECKDATASIG is copying Blockstream, and is inferior to OP_DATASIGVERIFY

Hi all,
Bitcoin-ABC's implementation of Bitcoin Cash is set to hard fork on November 18th, activating a bunch of features aimed at enhencing the usability of the currency.
One of the proposed improvements is OP_CHECKDATASIG, which can be used to run a verify operation on a (signature, message hash, pubkey) triplet. By itself, this is an extremely useful opcode to have. It allows one to embed an arbitrary message to the transaction, and these messages can then be used in applications external to the chain, or as an way to allow delegated signatures on top of the script itself that is being verified. Pretty cool.
OP_CHECKDATASIG is also exceptional for a different reason. In particular, it is an almost exact line-by-line copy of a little-known, yet fairly mature opcode called OP_CHECKSIGFROMSTACK, implemented here : https://github.com/ElementsProject/elements/commit/c35693257ca59b80659cfc4a965311f028c2d751#diff-be2905e2f5218ecdbe4e55637dac75f3R1328
For those who haven't been following, Elements is a project created by Blockstream, and elements alpha is a sidechain where experimental features can be added and tested. This commit from October 2016 shows (among other things) the addition of OP_CHECKSIGFROMSTACK to the elements alpha chain. Compared to the recent addition of OP_CHECKDATASIG to the bitcoin-abc client, the similarity is obvious : https://reviews.bitcoinabc.org/source/bitcoin-abc/change/mastesrc/script/interpreter.cpp;9ba4bfca513d6386ee3d313b15bdd4584da7633d
On the other hand, consider Bitcoin Unlimited's OP_DATASIGVERIFY : https://github.com/BitcoinUnlimited/BitcoinUnlimited/commit/1bf53307cab5d96076721ef5a238a63b03aca07d#diff-be2905e2f5218ecdbe4e55637dac75f3R970
This looks more like an independent development. It allows the same functionality as OP_CHECKDATASIG, but it does so in a way which is more transparent and also accessible for normal users. What I mean by that is, recall the verification parameters passed to OP_CHECKDATASIG, these were (signature, message hash, pubkey). For OP_DATASIGVERIFY, the parameters are slightly different: (signature, message, pubkey hash). The difference is subtle, but important. OP_DATASIGVERIFY follows the same design pattern as the widely known signmessage and verifymessage features that are implemented by various wallets (and in use by services like https://vote.bitcoin.com/ ). That is, a raw message is signed for and published by the user to the world, and independent verifiers are able to match the published signature and message to a specific pubkey hash - the data that makes up the user's on-chain address. If you've ever used this message signing and verifying feature of your wallet, you probably know how useful it can be. In contrast, OP_CHECKDATASIG verifies a message hash, not a plaintext message, against a pubkey, not a public address. This means that for a verifymessage-like operation, the script used in the transaction would become quite cumbersome:

  OP_HASH256[1]  OP_DUP OP_TOALTSTACK[2] OP_CHECKDATASIGVERIFY[3] OP_FROMALTSTACK OP_HASH160[4]  OP_EQUALVERIFY 

  1. We want to publish a plaintext message, but we have to "feed" its hash to OP_CHECKDATASIGVERIFY, so we have to use an OP_HASH256
  2. The pubkey we provide for verification will be "used up" by OP_CHECKDATASIGVERIFY, so we must both duplicate it and keep the copy in altstack
  3. OP_CHECKDATASIGVERIFY behaves exactly like OP_CHECKDATASIG, except that it fails the entire script immediately if the signature fails to verify
  4. We have the pubkey, but we still have to check that its hash matches the address, so we use OP_HASH160 and test for equality. Note that this means that we have to publis both public key /and/ its hash in the same transaction. Almost too wasteful.

Using OP_DATASIGVERIFY instead, the script is simply:
   OP_DATASIGVERIFY 

Hashing of the plaintext message is done internally by the OP_DATASIGVERIFY operation, and the same is also true for the hashing of the resulting public key against the provided pubkey hash (the data that makes up the address). A second not-so-obvious difference is the actual content of in the two scripts. For the OP_DATASIGVERIFY script, this message is actually parsed and verified using the exact same format as verifymessage in the wallet. This means that services like blockchain explorers can then simply decode the data in such a transaction and present it to users in a manner that enables them to run local verification of the message using their own wallet, simply by copy+pasting the information! Using OP_CHECKDATASIG instead, the does not follow the same semantics and format as the one in verifymessage, and no wallet exists today which support such a verifying operation in the UI. It is also hard to expect something like verifydatasigmessage to be implemented on absolutely all wallets.
I think it benefits of OP_DATASIGVERIFY when measured against OP_CHECKDATASIG are obvious, and am curious to hear your opinions.
submitted by moosapor to btc [link] [comments]

Tron v10.8.9 (2020-01-11) // Fix Internet Connectivity Check bug; fix obscure MBAM launch bug; fix SIV crash on Win10 Insider builds

Background

Tron is a script that "fights for the User." Think of it as a Tech on a thumb drive that automates ~85% of the tedious work in cleaning a Windows system, with some things left to the discretion of the tech. It is built with heavy reliance on community input and updated regularly.

Sequence of operation

Prep > Tempclean > De-bloat > Disinfect > Repair > Patch > Optimize > Wrap-up | Manual tools
Saves a log to C:\logs\tron\tron.log (configurable).
screenshots of Tron in action

Changelog

(significant changes in bold; full changelog on Github)
v10.9.0 (2020-01-13)
! Fix script-breaking syntax bug in Stage 3
v10.8.9 (2020-01-11)
! Fix bluescreen/greenscreen crash on Win10 insider builds when pulling system information using siv.exe. Thanks to u/iamzacharyrs
! Fix error where we'd attempt to launch %MBAM% but the variable was empty. Thanks to u/thementallydeceased
! Fix bug where we were inadvertently disabling the Internet Connectivity Check, which makes Office 365 unhappy. Thanks to u/shadenoah
* Definition and sub-tool updates

Download

  1. Primary method: Download the .torrent.
  2. Secondary: Download a self-extracting .exe pack from one of the mirrors:
    Mirror HTTPS HTTP Location Host
    Official link link US-TX u/SGC-Hosting
    #1 link link US-NY u/danodemano
    #3 link link DE u/bodrino
    #4 link link US/EU u/mxmod
    #5 link --- US-MI u/ajcutshall
    #6 link --- AU u/agent-squirrel
    #7 link --- GB-LND u/FreezerMoosh
    #8 link --- US-MO u/OlderGeeks
    #9 link --- Amazon CDN u/helpdesktv
    #10 link --- Global CDN Softpedia
  3. Tertiary: Connect to the Syncthing repo (instructions) to get fixes/updates immediately. This method has some risks and you should only use it if you understand them.
  4. Quaternary: Source code
    Source code is available on Github (Note: this doesn't include many of the utilities Tron relies on to function). If you want to view the code without downloading a ~600MB package, Github is a good place to do it.

Command-Line Support

Tron has full command-line support. Switches are optional, can be used simultaneously, and override their respective default when used. See here for a list of command-line switches.

Pack Integrity

SHA-256 hashes are contained in \tron\integrity_verification\checksums.txt and are signed with my PGP key; included. Use this to verify pack integrity.

Donations

Tron will always be free and open-source. If you'd like to buy me a beer or ... more importantly Scotch... you can waste money here:
and I guarantee it will go to waste
  • Patreon
  • Bitcoin: 1Biw8gx2kD7mZf66ZdNgB9tG1pE9YA3kEd
  • Bitcoin Cash: 18sXTTrAViPZVQtm63zBK6aCK3XfJpEThk
  • Monero (preferred): 4GG9KsJhwcW3zapDw62UaS71ZfFBjH9uwhc8FeyocPhUHHsuxj5zfvpZpZcZFHWpxoXD99MVt6PnR9QfftXDV8s6HbYdDuZEDZ947uiEje
These addresses go directly to u/vocatus. If you wish to support another volunteer (e.g. the incredibly generous u/SGC-Hosting) please contact them directly.

Problems and Support

Please look here first for a list of common issues (Tron appearing to be stalled, etc). If it doesn't answer your issue, make a top-level post to TronScript and myself or one of the community members will look at the issue. Additionally, you can reach me 24/7 on Keybase.
\integrity verification contains checksums.txt and is signed with my PGP key (0x07d1490f82a211a2, pubkey included). Use this to verify the pack.
"Do not withhold good from those to whom it is due, when it is in your power to act." -p3:27
submitted by vocatus to TronScript [link] [comments]

Bitcoin: ScriptSig And ScriptPubKey Terminology - Part11 Bitcoin Lesson  Script Legit Bitcoin Mining Site  2020  HashRapid - YouTube How To Obtaining an Extended Public Key xPub From Blockchain Wallet Dissecting a P2PKH Bitcoin Transaction down to the last Byte

Pay To Pubkey Hash. This script pattern is used to “send” someone bitcoins. It’s the most common script used for locking an output to someone’s public key. It is similar to P2PK, but the lock contains the hash of a public key instead (and not the public key itself). How does P2PKH work? The P2PKH script pattern contains a hashed public key surrounded by these opcodes: scriptPubKey ... A Bitcoin address is actually an encoded public key hash. The public key is hashed with SHA-256 and RIPEMD160, a version byte is added and a checksum is created, and then the address is encoded with Base 58 which gives the normal bitcoin address you see day-to-day. Pubkey To Hash. Converts a public key to a hash 160. Home; hash tools; Pubkey To Hash; Convert Pubkey To Hash. Lookup. Similar tools. Pubkey To Address. Converts a public key to an Address. hash tools. Address To Hash. Converts a bitcoin address to a hash 160. hash tools. Bitcoin tools. Check Bitcoin addresses balance, sent and received bitcoins, convert hashes, generate public keys and more ... The bitcoin system has a locking and unlocking mechanism. The locking is done with the pubkey script: the author of a tx defines the target (to whom the tx shall go), and the spending condition(s). This is were in P2PKH tx the hash of the public key goes. The spending condition is then s.th. like this "you need to provide a value, that when hashed, equals the provided public key hash in this ... Bitcoin tools. Check Bitcoin addresses balance, sent and received bitcoins, convert hashes, generate public keys and more! Donate. Tools. Block Eta; Pubkey To Address ; Address Balance; Address First Seen; Address Sent; Address Received; Address To Hash; Average transaction number; Average transaction size; Average transaction value; Block Count; Block Interval; Block Probability; Block Reward ...

[index] [28247] [34472] [34062] [38149] [2271] [31022] [17725] [49423] [42956] [6164]

Bitcoin: ScriptSig And ScriptPubKey Terminology - Part11

In this video, we go over the terminology needed to understand scriptsig and scriptpubkey. We go over public key, private key, public key hash, public address, digital signature and hash160. We ... Blockchain/Bitcoin for beginners 8: Bitcoin addresses, public key hash, P2PKH transactions - Duration: 23:28. Matt Thomas 13,816 views. 23:28. OAuth 2.0 and OpenID Connect (in plain English ... Before we delve into the inner workings of a bitcoin transaction I wanted to explain how the actual bitcoin address is derived from the public key which in turn is derived from the private key. I ... link: https://hashrapid.io/1698470 We aim to understand how bitcoin nodes validate a bitcoin transaction by concatenation of output and input scripts . Therefor we analyze the format of Bitcoin transaction. This is needed to ...

#