Bitcoin Forum
June 20, 2021, 11:11:27 PM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 [All]
  Print  
Author Topic: Taproot proposal  (Read 8939 times)
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
May 07, 2019, 12:03:27 AM
Merited by fillippone (7), Welsh (6), hugeblack (6), suchmoon (4), Foxpup (3), Carlton Banks (3), bitbollo (3), LoyceV (2), nutildah (2), Jating (2), bones261 (2), o_e_l_e_o (2), Heisenberg_Hunter (2), DdmrDdmr (2), DireWolfM14 (2), Coding Enthusiast (2), OgNasty (1), d5000 (1), JayJuanGee (1), mindrust (1), o48o (1), ETFbitcoin (1), franckuestein (1), DroomieChikito (1), 1miau (1), notblox1 (1), Xavofat (1), NotATether (1)
 #1

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html

Quote
Hello everyone,

Here are two BIP drafts that specify a proposal for a Taproot
softfork. A number of ideas are included:

* Taproot to make all outputs and cooperative spends indistinguishable
from eachother.
* Merkle branches to hide the unexecuted branches in scripts.
* Schnorr signatures enable wallet software to use key
aggregation/thresholds within one input.
* Improvements to the signature hashing algorithm (including signing
all input amounts).
* Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
batch validation.
* Tagged hashing for domain separation (avoiding issues like
CVE-2012-2459 in Merkle trees).
* Extensibility through leaf versions, OP_SUCCESS opcodes, and
upgradable pubkey types.

The BIP drafts can be found here:
* https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
specifies the transaction input spending rules.
* https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki
specifies the changes to Script inside such spends.
* https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
is the Schnorr signature proposal that was discussed earlier on this
list (See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html)

An initial reference implementation of the consensus changes, plus
preliminary construction/signing tests in the Python framework can be
found on https://github.com/sipa/bitcoin/commits/taproot. All
together, excluding the Schnorr signature module in libsecp256k1, the
consensus changes are around 520 LoC.

While many other ideas exist, not everything is incorporated. This
includes several ideas that can be implemented separately without loss
of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,
which we're working on as an independent proposal.

The document explains basic wallet operations, such as constructing
outputs and signing. However, a wide variety of more complex
constructions exist. Standardizing these is useful, but out of scope
for now. It is likely also desirable to define extensions to PSBT
(BIP174) for interacting with Taproot. That too is not included here.

Cheers,

--
Pieter
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1624230687
Hero Member
*
Offline Offline

Posts: 1624230687

View Profile Personal Message (Offline)

Ignore
1624230687
Reply with quote  #2

1624230687
Report to moderator
1624230687
Hero Member
*
Offline Offline

Posts: 1624230687

View Profile Personal Message (Offline)

Ignore
1624230687
Reply with quote  #2

1624230687
Report to moderator
1624230687
Hero Member
*
Offline Offline

Posts: 1624230687

View Profile Personal Message (Offline)

Ignore
1624230687
Reply with quote  #2

1624230687
Report to moderator
fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
May 07, 2019, 07:15:30 AM
Last edit: May 07, 2019, 07:45:32 AM by fillippone
Merited by mindrust (1)
 #2

Fillippone just  a pawn in the game of Bitcoin, I have enormous amount of respect for Bitcoin developers, and the following statement doesn’t absolutely mean to disrespect the huge work behind this proposal: I fully endorse and how will evolve in a Bitcoin protocol enchantment.
Writing this disclaimer because I got misunderstood in some previous discussions.

The more you build on bitcoin protocol, the more it is difficult to change the protocol itself.
With L2 solution (LN and  Liquid) being more and more widespread, and impacting Btc ecosystem, and L3 solutions peeking over the horizon (see my monthly recap),  I guess those are the last possible chances to get something done at protocol level.
Protocol immutability is a feature, not a bug.
Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

aliashraf
Legendary
*
Offline Offline

Activity: 1344
Merit: 1025

Always remember the cause!


View Profile WWW
May 07, 2019, 08:58:51 AM
Merited by Welsh (4), ETFbitcoin (1), hugeblack (1)
 #3

Fillippone just  a pawn in the game of Bitcoin, I have enormous amount of respect for Bitcoin developers, and the following statement doesn’t absolutely mean to disrespect the huge work behind this proposal I fully endorse and how will evolve in a BItcoin protocol enanchments.
Writing this because I got misunderstood in some previous discussions.

The more you build on bitcoin protocol, the more it is difficult to change the protocol itself.
With L2 solution (LN and  Liquid) being more and more widespread, and impacting Btc ecosystem, and L3 solutions peeking over the horizon (see my monthly recap),  I guess those are the last possible chances to get something done at protocol level.
Protocol immutability is a feature, not a bug.
Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

Absolutely disagree. Although making an analogy between bitcoin and TCP/IP is void and meaningless it would be worth mentioning how a semi-decentralized infrastructure like TCP/IP was ruined by L2 protocols like SMTP and HTTP giving birth to Internet giants like Google, Facebook, Netflix, YouTube, etc.

It is easy to make void analogies and waste your and other people's valuable time by advocating for L2 and L3 garbage that have nothing to do with basic ideas of cryptocurrency, among them decentralization and anti-censorship. Every shallow minded junior software engineer is able to make fantasies about layers above layers of protocols, feeling smart to understand protocol stacking. They are always prone to this class of mistakes, using design patterns as templates that are applicable to every problem without gap analysis.

There is a gap between bitcoin and a networking protocol like TCP/IP: bitcoin is a decentralized application while TCP/IP is a semi-decentralized transport protocol, a good engineer should beware of this gap and avoid stupid analogies between the two.

What is hard, the real challenge of bitcoin is improving it in consensus level such that it can accomplish its original mission as a p2p electronic cash system in a scalable fashion without compromising security and decentralization measures. Bitcoin Core developers has escalated this hurdle to an upper level by discouraging (even fighting against) hard forks. Unlike them, I don't see any reason to be such dogmatic about chain splits and hard forks, actually I see a handful of good reasons to have an overhaul every one decade or so.

My first impressions about Taproot proposal:
  • A good, still conservative step, forward.
  • So many critical problems not addressed.

Let's read the details and discuss later.



             ▄██▄
   ▄██▄      ▀█▀▀     ▄██▄
   ▀██▀▄  ▄▄█████▄▄  ▐███▀
       ███████████████
      ████████▀▄▄▄▀████
 ▄▄  ▐███▀▄▀██▄▀▀▀▄█████  ▄▄
████▀█████▄███▀▀█████ ██▀████
 ▀▀  ▐███▄███ ██ ████ █▌  ▀▀
      ▀████▄██▄▄███▀▄█▀
    ▄▄ █▀██████▀▄▄▄█▀█ ▄▄
   ████▀   ▀▀▀█▀▀▀   ▐████
    ▀▀       ▄██▄      ▀▀
             ▀██▀
⟩ ⟩ ⟩             ▄▄▄
  ▄▄▄▄▄▄▄▄▄▄█   █▄
 █           ▀▀▀  █
 ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀
▄▀▀ ▄▄▄▄▄▄▄▄▄▄▄▄ ▀▀▄
█ ▄▀ ▄▄▄▄▄▄▄    ▀█ █
█ █ █       █    █ ▄
█ █ ▄▀▀▀▀▀▀▄▄    █ █
█ █ ▀▄▄▄▄▀▀▄▄▀▀▄ █ █
█ █ █   █  ██  █ █ █
█ █ ▄▀▀▀▀▄▄▀▀▄▄▀ █ █
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ █
 ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
⟩ ⟩ ⟩       ▄████▄  ▄████▄
      ████████████████
      ████████████████
       ██████████████
        ▀██████████▀
██        ▀██████▀        ██
██▌   ▄            ▄   ▐██
███  ███▄          ▄███  ███
▀███▄ ▀███▄      ▄███▀ ▄███▀
  ▀████████      ████████▀
     ▀████▀      ▀████▀
     ▄   ▄▄      ▄▄   ▄
     ▀█████      █████▀
fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
May 07, 2019, 09:13:16 AM
 #4

I am not a software engineer, so I am no way qualified to judge your more technical remarks.
For sure i can criticise the analogy with Facebook, but I won't indulge in that because if the basic analogy Bitcoin (protocol) <=> TCP/IP is not good, every derivate analogy will be bad too.

The point is I always say Bitcoin as a protocol, not as an application, as I said, I am not a software engineer, so I will dig more into this.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1904
Merit: 2821


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
May 07, 2019, 05:09:56 PM
Last edit: May 07, 2019, 06:40:24 PM by ETFbitcoin
 #5

After quick research, i just realized Taproot is combination of Schnorr and MAST. No wonder i never see any news about MAST.

I wonder if HTLC on Lightning Network can use Taproot (which would save fees/reduce tx size when open/close channel)?

Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

I disagree, if there's way to optimize "lower" layer which also backward-compatible. I don't see anything wrong with it.
I'd agree if we're talking about implement complex feature on "lower" layer.

Carlton Banks
Legendary
*
Offline Offline

Activity: 3122
Merit: 2488



View Profile
May 07, 2019, 06:31:58 PM
Last edit: May 07, 2019, 08:51:16 PM by Carlton Banks
Merited by Foxpup (3), bones261 (2), nc50lc (2), gmaxwell (1), fronti (1), ETFbitcoin (1), hugeblack (1), darosior (1)
 #6

I wonder if HTLC on Lightning Network can use Taproot (which would save fees/reduce tx size when open/close channel)?

Yes

Lightning channels have 2 scripts branches ("update" and "close"). If one were using these proposed taproot enabled segwit v1 outputs, the update branch will only ever be processed when the channel is open, and does not need to be written to the blockchain at all when closing the channel. Conversely, the close branch is not written to the chain when opening the channel.

This not only optimises space usage on-chain, but also makes lightning open/close transactions more closely resemble regular transactions, and so improves fungibility. I think it's possible with taproot and signature aggregation (which is not in this proposed fork) to make channel open/close tx's indistinguishable from regular tx's on chain (and potential changes to aid scaling of lightning routing will mean that only a small subset of LN nodes will be aware of the existence of a given channel, so knowing where and when BTC enters and exits payment channels will be a much more difficult problem to solve)

Edit: it's better than I thought, it seems only a specific form of sig aggregation ("cross input aggregation") is not in this fork proposal, but the basic type is (where signatures in a single transaction are summed together). No idea how cross input form differs from the basic type, still reading...


Vires in numeris
fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
May 07, 2019, 06:35:33 PM
 #7

After quick research, i just realized Taproot is combination of Schnorr and MAST. No wonder i never see any news about MAST.

I wonder if HTLC on Lightning Network can use Taproot (which would save fees/reduce tx size when open/close channel)?
But if Bitcoin use rolling-release/progressive approach (which is very unlikely)

Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

I disagree, if there's way to optimize "lower" layer which also backward-compatible. I don't see anything wrong with it.
I'd agree if we're talking about implement complex feature on "lower" layer.
Sure, I agree on that, but what I mean is that if you build multiple protocol layers over the fundamental layer of Bitcoin protocol, if you modify anything on the lower one, the risk of getting something wrecked in the upper layers increases dramatically.
So when you build many layers over Bitcoin protocol, this get “compressed as a Jenga piece” and becomes immutable, as the risk of touching it and wrecking something somewhere becomes too high.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1904
Merit: 2821


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
May 07, 2019, 06:44:11 PM
Merited by fillippone (1)
 #8

Yes
--snip--

Thanks for detailed explanation Smiley

Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

I disagree, if there's way to optimize "lower" layer which also backward-compatible. I don't see anything wrong with it.
I'd agree if we're talking about implement complex feature on "lower" layer.
Sure, I agree on that, but what I mean is that if you build multiple protocol layers over the fundamental layer of Bitcoin protocol, if you modify anything on the lower one, the risk of getting something wrecked in the upper layers increases dramatically.
So when you build many layers over Bitcoin protocol, this get “compressed as a Jenga piece” and becomes immutable, as the risk of touching it and wrecking something somewhere becomes too high.

Can't disagree with that, but :
1. That's why we always wait years for new improvement, due to through-full testing
2. Many improvement add new feature rather than modify existing feature, such as creating P2SH address for scripting and Bech32 for SegWit.

gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
May 07, 2019, 10:20:10 PM
Merited by Foxpup (2), actmyname (1), hugeblack (1), fillippone (1)
 #9

Sure, I agree on that, but what I mean is that if you build multiple protocol layers over the fundamental layer of Bitcoin protocol, if you modify anything on the lower one, the risk of getting something wrecked in the upper layers increases dramatically.
The Bitcoin protocol has specific carve outs for extension. New extensions are done using these carve-outs. This largely avoids impact on things not using the new functionality.

One can not guarantee a complete lack of interaction-- after all, things built on bitcoin could be full of terrible bugs just waiting to be exploited, and any new behaviour might trigger one of those bugs--, but nothing new shows up in transactions that wasn't permitted all along which at least guarantees that nothing changed that some party couldn't have unilaterally done to you.

The reason technical commentators don't express your concern isn't because it hasn't occurred to them, it's because it has occurred and is largely addressed.

I find it kinda frustrating that no one bothers mentioning concerns like this in the crazy "bitcoin should hardfork once a quarter" threads. Sad -- why must this kind of concern be conserved for sane proposals where it doesn't really apply?
Wind_FURY
Legendary
*
Offline Offline

Activity: 1862
Merit: 1121


www.Crypto.Games: Multiple coins, multiple games


View Profile
May 08, 2019, 08:16:01 AM
Merited by gmaxwell (1), hatshepsut93 (1), hugeblack (1)
 #10

Fillippone just  a pawn in the game of Bitcoin, I have enormous amount of respect for Bitcoin developers, and the following statement doesn’t absolutely mean to disrespect the huge work behind this proposal I fully endorse and how will evolve in a BItcoin protocol enanchments.
Writing this because I got misunderstood in some previous discussions.

The more you build on bitcoin protocol, the more it is difficult to change the protocol itself.
With L2 solution (LN and  Liquid) being more and more widespread, and impacting Btc ecosystem, and L3 solutions peeking over the horizon (see my monthly recap),  I guess those are the last possible chances to get something done at protocol level.
Protocol immutability is a feature, not a bug.
Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

Absolutely disagree. Although making an analogy between bitcoin and TCP/IP is void and meaningless it would be worth mentioning how a semi-decentralized infrastructure like TCP/IP was ruined by L2 protocols like SMTP and HTTP giving birth to Internet giants like Google, Facebook, Netflix, YouTube, etc.

It is easy to make void analogies and waste your and other people's valuable time by advocating for L2 and L3 garbage that have nothing to do with basic ideas of cryptocurrency, among them decentralization and anti-censorship. Every shallow minded junior software engineer is able to make fantasies about layers above layers of protocols, feeling smart to understand protocol stacking. They are always prone to this class of mistakes, using design patterns as templates that are applicable to every problem without gap analysis.


But every junior developer could also feel smart, and make fantasies of a perfect blockchain-based cryptocurrency too, without any regard for externalities, or without any regard for the risks in messing up the consensus layer.

Quote

There is a gap between bitcoin and a networking protocol like TCP/IP: bitcoin is a decentralized application while TCP/IP is a semi-decentralized transport protocol, a good engineer should beware of this gap and avoid stupid analogies between the two.

What is hard, the real challenge of bitcoin is improving it in consensus level such that it can accomplish its original mission as a p2p electronic cash system in a scalable fashion without compromising security and decentralization measures.


Says who?

Quote

Bitcoin Core developers has escalated this hurdle to an upper level by discouraging (even fighting against) hard forks. Unlike them, I don't see any reason to be such dogmatic about chain splits and hard forks, actually I see a handful of good reasons to have an overhaul every one decade or so.


That's your opinion. An opinion that many in the community do not share.

████  ███████  ███
██████████
███      ███████
███      ███████████
██████████████████
████████
███   ████  ███████████
███ ███████████████
█████████
█████████████████
███  ███████
██████████████
███        ████████
███████████▀▀███▀▀███████████
██████▀▀     ███     ▀▀██████
████▀   ▄▄█████████▄▄   ▀████
████▄▄▄███▀  ▀█▀  ▀███▄▄▄████
██▀▀▀██▀      ▀      ▀██▀▀▀██
█▀  ▄██               ██▄  ▀█
█   ████▄▄         ▄▄████   █
█▄  ▀██▀             ▀██▀  ▄█
██▄▄▄██▄             ▄██▄▄▄██
████▀▀▀███▄ ▄█ █▄ ▄███▀▀▀████
████▄   ▀▀███▄█████▀▀   ▄████
███████▄     ███     ▄███████
███████████▄▄███▄▄███████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
..PLAY NOW..
███  ███████  ████
██████████
███████      ███
███████████      ███
██████████████████
████████
███████████  ████   ███
███████████████ ███
█████████
█████████████████
███████  ███
██████████████
████████        ███
aliashraf
Legendary
*
Offline Offline

Activity: 1344
Merit: 1025

Always remember the cause!


View Profile WWW
May 08, 2019, 09:37:52 AM
Last edit: May 08, 2019, 10:08:45 AM by aliashraf
Merited by hugeblack (1)
 #11

Sure, I agree on that, but what I mean is that if you build multiple protocol layers over the fundamental layer of Bitcoin protocol, if you modify anything on the lower one, the risk of getting something wrecked in the upper layers increases dramatically.
The Bitcoin protocol has specific carve outs for extension. New extensions are done using these carve-outs. This largely avoids impact on things not using the new functionality.

One can not guarantee a complete lack of interaction-- after all, things built on bitcoin could be full of terrible bugs just waiting to be exploited, and any new behaviour might trigger one of those bugs--, but nothing new shows up in transactions that wasn't permitted all along which at least guarantees that nothing changed that some party couldn't have unilaterally done to you.

The reason technical commentators don't express your concern isn't because it hasn't occurred to them, it's because it has occurred and is largely addressed.

I find it kinda frustrating that no one bothers mentioning concerns like this in the crazy "bitcoin should hardfork once a quarter" threads. Sad -- why must this kind of concern be conserved for sane proposals where it doesn't really apply?

I hope it wouldn't cause more frustrations but I think both Ethereum approach (hard-forking like quarterly) and yours (do it never ever) to cryptocurrency governance should be categorized as extremism and need to be reconsidered.

Above-thread I objected to @fillippone not to the problem he has brought up but to his solution. He pushes your extremism to its limits and its destiny: leave bitcoin as is! When you abandon radical improvements they need to be implemented on upper layers and besides the centralization and censorship threats involved there will be always a push like that: Don't touch my infrastructure please!

I am against L2 solutions, I think both mining/state-verification in a decentralized ecosystem and on-chain scalability of bitcoin are not achievable without applying revisions in some crucial choices Satoshi made from the first beginning: winner-takes-all approach to mining and linear structure of the blockchain. There is no soft way to do such revisions and no L2 solution would ever solve both scaling and centralization.

Issuing anathema statements against radical improvement proposals that typically involve hard-fork requirements is nothing less than condemning bitcoin.

             ▄██▄
   ▄██▄      ▀█▀▀     ▄██▄
   ▀██▀▄  ▄▄█████▄▄  ▐███▀
       ███████████████
      ████████▀▄▄▄▀████
 ▄▄  ▐███▀▄▀██▄▀▀▀▄█████  ▄▄
████▀█████▄███▀▀█████ ██▀████
 ▀▀  ▐███▄███ ██ ████ █▌  ▀▀
      ▀████▄██▄▄███▀▄█▀
    ▄▄ █▀██████▀▄▄▄█▀█ ▄▄
   ████▀   ▀▀▀█▀▀▀   ▐████
    ▀▀       ▄██▄      ▀▀
             ▀██▀
⟩ ⟩ ⟩             ▄▄▄
  ▄▄▄▄▄▄▄▄▄▄█   █▄
 █           ▀▀▀  █
 ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀
▄▀▀ ▄▄▄▄▄▄▄▄▄▄▄▄ ▀▀▄
█ ▄▀ ▄▄▄▄▄▄▄    ▀█ █
█ █ █       █    █ ▄
█ █ ▄▀▀▀▀▀▀▄▄    █ █
█ █ ▀▄▄▄▄▀▀▄▄▀▀▄ █ █
█ █ █   █  ██  █ █ █
█ █ ▄▀▀▀▀▄▄▀▀▄▄▀ █ █
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ █
 ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
⟩ ⟩ ⟩       ▄████▄  ▄████▄
      ████████████████
      ████████████████
       ██████████████
        ▀██████████▀
██        ▀██████▀        ██
██▌   ▄            ▄   ▐██
███  ███▄          ▄███  ███
▀███▄ ▀███▄      ▄███▀ ▄███▀
  ▀████████      ████████▀
     ▀████▀      ▀████▀
     ▄   ▄▄      ▄▄   ▄
     ▀█████      █████▀
aliashraf
Legendary
*
Offline Offline

Activity: 1344
Merit: 1025

Always remember the cause!


View Profile WWW
May 08, 2019, 10:04:07 AM
 #12

But every junior developer could also feel smart, and make fantasies of a perfect blockchain-based cryptocurrency too, without any regard for externalities, or without any regard for the risks in messing up the consensus layer.
And senior developers, (like you and Greg  Tongue) should remain open to such proposals and use them at least as an inspiration to confront the real problems instead of sticking with false analogies with a networking protocol and being happy with minor improvements, Right?


Quote
There is a gap between bitcoin and a networking protocol like TCP/IP: bitcoin is a decentralized application while TCP/IP is a semi-decentralized transport protocol, a good engineer should beware of this gap and avoid stupid analogies between the two.

What is hard, the real challenge of bitcoin is improving it in consensus level such that it can accomplish its original mission as a p2p electronic cash system in a scalable fashion without compromising security and decentralization measures.


Says who?
I say  Cool

             ▄██▄
   ▄██▄      ▀█▀▀     ▄██▄
   ▀██▀▄  ▄▄█████▄▄  ▐███▀
       ███████████████
      ████████▀▄▄▄▀████
 ▄▄  ▐███▀▄▀██▄▀▀▀▄█████  ▄▄
████▀█████▄███▀▀█████ ██▀████
 ▀▀  ▐███▄███ ██ ████ █▌  ▀▀
      ▀████▄██▄▄███▀▄█▀
    ▄▄ █▀██████▀▄▄▄█▀█ ▄▄
   ████▀   ▀▀▀█▀▀▀   ▐████
    ▀▀       ▄██▄      ▀▀
             ▀██▀
⟩ ⟩ ⟩             ▄▄▄
  ▄▄▄▄▄▄▄▄▄▄█   █▄
 █           ▀▀▀  █
 ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀
▄▀▀ ▄▄▄▄▄▄▄▄▄▄▄▄ ▀▀▄
█ ▄▀ ▄▄▄▄▄▄▄    ▀█ █
█ █ █       █    █ ▄
█ █ ▄▀▀▀▀▀▀▄▄    █ █
█ █ ▀▄▄▄▄▀▀▄▄▀▀▄ █ █
█ █ █   █  ██  █ █ █
█ █ ▄▀▀▀▀▄▄▀▀▄▄▀ █ █
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ █
 ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
⟩ ⟩ ⟩       ▄████▄  ▄████▄
      ████████████████
      ████████████████
       ██████████████
        ▀██████████▀
██        ▀██████▀        ██
██▌   ▄            ▄   ▐██
███  ███▄          ▄███  ███
▀███▄ ▀███▄      ▄███▀ ▄███▀
  ▀████████      ████████▀
     ▀████▀      ▀████▀
     ▄   ▄▄      ▄▄   ▄
     ▀█████      █████▀
Carlton Banks
Legendary
*
Offline Offline

Activity: 3122
Merit: 2488



View Profile
May 08, 2019, 01:10:35 PM
 #13

Says who?
I say  Cool

right, and you make up your own facts

("miners broke the SHA-2 algorithm" which is demonstrably nonsense)

Vires in numeris
aliashraf
Legendary
*
Offline Offline

Activity: 1344
Merit: 1025

Always remember the cause!


View Profile WWW
May 08, 2019, 05:49:01 PM
Last edit: May 08, 2019, 06:04:06 PM by aliashraf
 #14

Says who?
I say  Cool

right, and you make up your own facts

("miners broke the SHA-2 algorithm" which is demonstrably nonsense)
This is an act of trolling,  Cheesy
@Wind_Fury started it by asking for ethos instead of logus and now you are accomplishing his job by directly questioning my right to say anything about bitcoin. Very interesting.

If you are mentioning my criticism about ASICs, it is indisputable. PoW is a cryptographic problem, it hates efficiency, any cryptographic scheme does. bitcoin basically was designed for owners of commodity devices with almost average efficiency who join and leave the network freely and voluntarily and pay fairly for blocks they mine:
Quote from: Satoshi Nakamoto, Bitcoin whitepaer
Nodes can leave   and   rejoin   the   network   at   will,   accepting   the   proof-of-work   chain   as   proof   of   what happened while they were gone.  They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them.  Any needed rules and incentives can be enforced with this consensus mechanism.

I think a better practice would be making your own argument about what I said above-thread:
What is hard, the real challenge of bitcoin is improving it in consensus level such that it can accomplish its original mission as a p2p electronic cash system in a scalable fashion without compromising security and decentralization measures. Bitcoin Core developers have escalated this hurdle to an upper level by discouraging (even fighting against) hard forks. Unlike them, I don't see any reason to be such dogmatic about chain splits and hard forks, actually I see a handful of good reasons to have an overhaul every one decade or so.

As a pro you might have noticed that I'm directly questioning Buterin's claim about the existence of a trilemma and suggesting that refuting this claim is the most important job of any serious bitcoin developer and the main agenda for any development project.

What do you think?

             ▄██▄
   ▄██▄      ▀█▀▀     ▄██▄
   ▀██▀▄  ▄▄█████▄▄  ▐███▀
       ███████████████
      ████████▀▄▄▄▀████
 ▄▄  ▐███▀▄▀██▄▀▀▀▄█████  ▄▄
████▀█████▄███▀▀█████ ██▀████
 ▀▀  ▐███▄███ ██ ████ █▌  ▀▀
      ▀████▄██▄▄███▀▄█▀
    ▄▄ █▀██████▀▄▄▄█▀█ ▄▄
   ████▀   ▀▀▀█▀▀▀   ▐████
    ▀▀       ▄██▄      ▀▀
             ▀██▀
⟩ ⟩ ⟩             ▄▄▄
  ▄▄▄▄▄▄▄▄▄▄█   █▄
 █           ▀▀▀  █
 ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀
▄▀▀ ▄▄▄▄▄▄▄▄▄▄▄▄ ▀▀▄
█ ▄▀ ▄▄▄▄▄▄▄    ▀█ █
█ █ █       █    █ ▄
█ █ ▄▀▀▀▀▀▀▄▄    █ █
█ █ ▀▄▄▄▄▀▀▄▄▀▀▄ █ █
█ █ █   █  ██  █ █ █
█ █ ▄▀▀▀▀▄▄▀▀▄▄▀ █ █
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ █
 ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
⟩ ⟩ ⟩       ▄████▄  ▄████▄
      ████████████████
      ████████████████
       ██████████████
        ▀██████████▀
██        ▀██████▀        ██
██▌   ▄            ▄   ▐██
███  ███▄          ▄███  ███
▀███▄ ▀███▄      ▄███▀ ▄███▀
  ▀████████      ████████▀
     ▀████▀      ▀████▀
     ▄   ▄▄      ▄▄   ▄
     ▀█████      █████▀
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
May 08, 2019, 08:28:31 PM
 #15

Can y'all please stop derailing this thread?
Wind_FURY
Legendary
*
Offline Offline

Activity: 1862
Merit: 1121


www.Crypto.Games: Multiple coins, multiple games


View Profile
May 09, 2019, 07:01:50 AM
 #16

Can y'all please stop derailing this thread?

Sorry.

aliasharf let's continue in this topic, https://bitcointalk.org/index.php?topic=5140929.0

████  ███████  ███
██████████
███      ███████
███      ███████████
██████████████████
████████
███   ████  ███████████
███ ███████████████
█████████
█████████████████
███  ███████
██████████████
███        ████████
███████████▀▀███▀▀███████████
██████▀▀     ███     ▀▀██████
████▀   ▄▄█████████▄▄   ▀████
████▄▄▄███▀  ▀█▀  ▀███▄▄▄████
██▀▀▀██▀      ▀      ▀██▀▀▀██
█▀  ▄██               ██▄  ▀█
█   ████▄▄         ▄▄████   █
█▄  ▀██▀             ▀██▀  ▄█
██▄▄▄██▄             ▄██▄▄▄██
████▀▀▀███▄ ▄█ █▄ ▄███▀▀▀████
████▄   ▀▀███▄█████▀▀   ▄████
███████▄     ███     ▄███████
███████████▄▄███▄▄███████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
..PLAY NOW..
███  ███████  ████
██████████
███████      ███
███████████      ███
██████████████████
████████
███████████  ████   ███
███████████████ ███
█████████
█████████████████
███████  ███
██████████████
████████        ███
Xieta
Member
**
Offline Offline

Activity: 61
Merit: 40


View Profile
November 07, 2019, 10:56:44 AM
 #17

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html

Quote
Hello everyone,

Here are two BIP drafts that specify a proposal for a Taproot
softfork. A number of ideas are included:

* Taproot to make all outputs and cooperative spends indistinguishable
from eachother.
* Merkle branches to hide the unexecuted branches in scripts.
* Schnorr signatures enable wallet software to use key
aggregation/thresholds within one input.
* Improvements to the signature hashing algorithm (including signing
all input amounts).
* Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
batch validation.
* Tagged hashing for domain separation (avoiding issues like
CVE-2012-2459 in Merkle trees).
* Extensibility through leaf versions, OP_SUCCESS opcodes, and
upgradable pubkey types.

The BIP drafts can be found here:
* https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
specifies the transaction input spending rules.
* https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki
specifies the changes to Script inside such spends.
* https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
is the Schnorr signature proposal that was discussed earlier on this
list (See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html)

An initial reference implementation of the consensus changes, plus
preliminary construction/signing tests in the Python framework can be
found on https://github.com/sipa/bitcoin/commits/taproot. All
together, excluding the Schnorr signature module in libsecp256k1, the
consensus changes are around 520 LoC.

While many other ideas exist, not everything is incorporated. This
includes several ideas that can be implemented separately without loss
of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,
which we're working on as an independent proposal.

The document explains basic wallet operations, such as constructing
outputs and signing. However, a wide variety of more complex
constructions exist. Standardizing these is useful, but out of scope
for now. It is likely also desirable to define extensions to PSBT
(BIP174) for interacting with Taproot. That too is not included here.

Cheers,

--
Pieter


It's a shame this thread derailed.
Is this still the current proposal or has the discussion on this moved elsewhere?

Best Regards,
-Xi
fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
January 23, 2020, 11:55:52 AM
Last edit: January 23, 2020, 12:17:46 PM by fillippone
Merited by Carlton Banks (1), squatter (1)
 #18

A Pull Request from Sipa (Pieter Wuille) for Taproot/Schnoorr consensus rules has been opened on the Bitcoin Core repository:
[WIP] Implement BIP 340-342 validation (Schnorr/taproot/tapscript) #17977

Quote
This is an implementation of the Schnorr/taproot consensus rules proposed by BIPs 340, 341, and 342 (see current bitcoin/bips#876).

It consists of:

#16902 to avoid the O(n^2) behavior in IF/ELSE/END handling that would be exacerbated by the BIP 342 changes.
Addition of Schnorr signatures and 32-byte pubkey support to libsecp256k1 subtree (bitcoin-core/secp256k1#558 PR 558), following BIP 340.
The taproot validation specified in BIP 341.
Script validation under taproot (aka tapscript), specified in BIP 342.
Addition of signing logic for Schnorr/Taproot to the Python test framework, and tests for the above.
This does not include any wallet support.

Merging this is obviously conditional on getting community support for the proposal. It's opened here to demonstrate the code changes that it would imply.

This is the first step toward  the most important protocol change since Segwit, I dare to state.


DooMAD
Legendary
*
Online Online

Activity: 2730
Merit: 1817


Leave no FUD unchallenged


View Profile WWW
January 23, 2020, 02:14:31 PM
 #19

This is the first step toward  the most important protocol change since Segwit, I dare to state.

Excellent news.  I suspect a number of people will be watching with keen interest.  Have there been any elaborations on timescales?  Or are the waters still a little murky for that with so much stuff to figure out on the technical side?  Obviously with a significant change like this, they'll be treading carefully.

Carlton Banks
Legendary
*
Offline Offline

Activity: 3122
Merit: 2488



View Profile
January 23, 2020, 03:42:25 PM
Merited by DooMAD (2), ETFbitcoin (1), o_e_l_e_o (1), fillippone (1)
 #20

A Pull Request from Sipa (Pieter Wuille) for Taproot/Schnoorr consensus rules has been opened on the Bitcoin Core repository:

big news indeed.


any elaborations on timescales?

the pull request is marked WIP (work in progress), so my guess would be no. I think sipa is just soliciting early feedback on his implementation of the BIPs (the details of which we can assume are essentially final)

Vires in numeris
fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
January 24, 2020, 12:36:54 AM
Last edit: January 24, 2020, 09:32:07 AM by fillippone
Merited by Carlton Banks (1), o_e_l_e_o (1)
 #21

the pull request is marked WIP (work in progress), so my guess would be no. I think sipa is just soliciting early feedback on his implementation of the BIPs (the details of which we can assume are essentially final)

Officially BIP!
Pieter Wuille on Twitter:
Quote
The Schnorr/Taproot proposal is now published as BIPs 340, 341, and 342; see github.com/bitcoin/bips/

Note that the assignment of BIP numbers is not any kind of stamp of approval; it just means the process was followed (which includes some amount of public discussion).
https://twitter.com/pwuille/status/1220502956023283718?s=21

EDIT:
For the non technical and casual reader an article surfaced on Coindesk:
Bitcoin’s Privacy and Scaling Tech Upgrade ‘Taproot’ Just Took a Big Step Forward

Wind_FURY
Legendary
*
Offline Offline

Activity: 1862
Merit: 1121


www.Crypto.Games: Multiple coins, multiple games


View Profile
January 24, 2020, 08:36:19 AM
 #22

This would clearly be the biggest Bitcoin update since Segwit on 2017. Are there some people within the community who are against it?

I hope no more drama ensues. Haha.

████  ███████  ███
██████████
███      ███████
███      ███████████
██████████████████
████████
███   ████  ███████████
███ ███████████████
█████████
█████████████████
███  ███████
██████████████
███        ████████
███████████▀▀███▀▀███████████
██████▀▀     ███     ▀▀██████
████▀   ▄▄█████████▄▄   ▀████
████▄▄▄███▀  ▀█▀  ▀███▄▄▄████
██▀▀▀██▀      ▀      ▀██▀▀▀██
█▀  ▄██               ██▄  ▀█
█   ████▄▄         ▄▄████   █
█▄  ▀██▀             ▀██▀  ▄█
██▄▄▄██▄             ▄██▄▄▄██
████▀▀▀███▄ ▄█ █▄ ▄███▀▀▀████
████▄   ▀▀███▄█████▀▀   ▄████
███████▄     ███     ▄███████
███████████▄▄███▄▄███████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
..PLAY NOW..
███  ███████  ████
██████████
███████      ███
███████████      ███
██████████████████
████████
███████████  ████   ███
███████████████ ███
█████████
█████████████████
███████  ███
██████████████
████████        ███
Carlton Banks
Legendary
*
Offline Offline

Activity: 3122
Merit: 2488



View Profile
January 24, 2020, 01:53:39 PM
Merited by fillippone (1)
 #23

the pull request is marked WIP (work in progress), so my guess would be no. I think sipa is just soliciting early feedback on his implementation of the BIPs (the details of which we can assume are essentially final)

Officially BIP!
Pieter Wuille on Twitter:
Quote
The Schnorr/Taproot proposal is now published as BIPs 340, 341, and 342; see github.com/bitcoin/bips/

Note that the assignment of BIP numbers is not any kind of stamp of approval; it just means the process was followed (which includes some amount of public discussion).

very positive that BIPs 340-342 are progressing, however mundane that is! I think though that the door is not shut on amendments, but this is still a milestone nevertheless.

I might add that I consider the Taproot soft-fork to be more significant than segwit, the improvement to BTC's money properties and the consequential impact to the overall bitcoin economy are far more substantial than the changes conferred by BIPs 140-144 (despite segwit providing several prerequisites that make taproot possible)

Vires in numeris
fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
January 24, 2020, 02:02:23 PM
 #24


very positive that BIPs 340-342 are progressing, however mundane that is! I think though that the door is not shut on amendments, but this is still a milestone nevertheless.

I might add that I consider the Taproot soft-fork to be more significant than segwit, the improvement to BTC's money properties and the consequential impact to the overall bitcoin economy are far more substantial than the changes conferred by BIPs 140-144 (despite segwit providing several prerequisites that make taproot possible)
I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

DooMAD
Legendary
*
Online Online

Activity: 2730
Merit: 1817


Leave no FUD unchallenged


View Profile WWW
January 24, 2020, 02:15:45 PM
 #25

This would clearly be the biggest Bitcoin update since Segwit on 2017. Are there some people within the community who are against it?

I hope no more drama ensues. Haha.

I'd anticipate that any conflicts would be purely verbal/written and not even remotely a threat to implementation.  I doubt we'll see any alternative codebases popping up in opposition or anything like that.

The usual detractors will follow their predictable routine of trash-talk and stirring the pot, but I suspect that's about as far as it'll go.

Carlton Banks
Legendary
*
Offline Offline

Activity: 3122
Merit: 2488



View Profile
January 24, 2020, 07:23:04 PM
Merited by gmaxwell (5)
 #26

I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

really, I think that it's unfair to everyone to discuss attempts to de-rail this proposal before any such attempts have occurred. it's certainly ironic considering this thread has already been drawn into personality clashes, which the OP was unhappy with seeing as this is the dev & technical board (for which I share some responsibility, regrettably)

Vires in numeris
fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
January 24, 2020, 07:33:04 PM
 #27

I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

really, I think that it's unfair to everyone to discuss attempts to de-rail this proposal before any such attempts have occurred. it's certainly ironic considering this thread has already been drawn into personality clashes, which the OP was unhappy with seeing as this is the dev & technical board (for which I share some responsibility, regrettably)
Point taken.
I wasn’t in any case suggesting anyone to derail anything or clash to anyone.

pereira4
Legendary
*
Offline Offline

Activity: 1610
Merit: 1177


View Profile
January 24, 2020, 11:42:43 PM
Merited by fillippone (3), cr1776 (1)
 #28

How far are we from rendering efforts like "chainanalysis" useless? As it stands, interacting with fiat exchanges is a risk by default. Most of us are regular people, we aren't criminals, yet, what those blacklisting services do is basically putting yourself into the insane liability of ending up in a risk linked to criminal activity because some of your addresses once pertained to an address that it's on their blacklists. On a long enough timeline, everyone's chances of having coins that are "tainted" increase to the point that it's absurd putting your coins in an exchange.

Every single wallet should be sending transactions that by default obfuscate things so no one is liable of this bullshit idea of having "tainted coins", in other words, actual fungibility. Until then, how is one supposed to deposit coins on exchanges? Again, as of right now, you are playing a sick lottery in which your coins may or not have traces of being tainted, and as time goes on and coins move, everyone's chances just keep going up.
figmentofmyass
Legendary
*
Offline Offline

Activity: 1652
Merit: 1480



View Profile
January 25, 2020, 02:06:13 PM
 #29

How far are we from rendering efforts like "chainanalysis" useless?

Every single wallet should be sending transactions that by default obfuscate things so no one is liable of this bullshit idea of having "tainted coins", in other words, actual fungibility.

obviously, schnorr signatures are on deck. that'll allow for cross-input aggregation to make coinjoins indistinguishable from regular transactions. that's a pretty massive development given that exchanges are beginning to target coinjoin users. estimating based on segwit's activation timeline, that could happen by early 2021 or maybe even the end of this year, optimistically.

but "useless"? that's quite a strong word. Lips sealed

confidential transactions (CT) to obfuscate transaction amounts seems like an attractive next step. but my understanding is it requires extension blocks or a hard fork. so.....probably not gonna be implemented at the consensus layer. there's always sidechains though. liquid (blockstream's sidechain) supports CT for example.

Wind_FURY
Legendary
*
Offline Offline

Activity: 1862
Merit: 1121


www.Crypto.Games: Multiple coins, multiple games


View Profile
January 26, 2020, 07:31:44 AM
Merited by PrimeNumber7 (1)
 #30

I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

really, I think that it's unfair to everyone to discuss attempts to de-rail this proposal before any such attempts have occurred. it's certainly ironic considering this thread has already been drawn into personality clashes, which the OP was unhappy with seeing as this is the dev & technical board (for which I share some responsibility, regrettably)


But, without intending to derail, what would be a good technical debate against this proposal? Is there one? I believe there's none, or else we would already hear about it from people like franky1.

████  ███████  ███
██████████
███      ███████
███      ███████████
██████████████████
████████
███   ████  ███████████
███ ███████████████
█████████
█████████████████
███  ███████
██████████████
███        ████████
███████████▀▀███▀▀███████████
██████▀▀     ███     ▀▀██████
████▀   ▄▄█████████▄▄   ▀████
████▄▄▄███▀  ▀█▀  ▀███▄▄▄████
██▀▀▀██▀      ▀      ▀██▀▀▀██
█▀  ▄██               ██▄  ▀█
█   ████▄▄         ▄▄████   █
█▄  ▀██▀             ▀██▀  ▄█
██▄▄▄██▄             ▄██▄▄▄██
████▀▀▀███▄ ▄█ █▄ ▄███▀▀▀████
████▄   ▀▀███▄█████▀▀   ▄████
███████▄     ███     ▄███████
███████████▄▄███▄▄███████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
..PLAY NOW..
███  ███████  ████
██████████
███████      ███
███████████      ███
██████████████████
████████
███████████  ████   ███
███████████████ ███
█████████
█████████████████
███████  ███
██████████████
████████        ███
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1904
Merit: 2821


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
January 26, 2020, 07:49:38 AM
Merited by fillippone (2), Husna QA (1)
 #31

Looking at the title of BIP 341 (Taproot: SegWit version 1 spending rules), does that mean we'll see address with prefix bc1p?

confidential transactions (CT) to obfuscate transaction amounts seems like an attractive next step. but my understanding is it requires extension blocks or a hard fork. so.....probably not gonna be implemented at the consensus layer. there's always sidechains though. liquid (blockstream's sidechain) supports CT for example.

Not only hardfork, but CT have bigger size compared with regular transaction (even if you combine CT with Bulletproof, just like what Monero did), so i doubt it'll gain massive support.

pooya87
Legendary
*
Offline Offline

Activity: 2394
Merit: 3931


Remember tonight for it's the beginning of forever


View Profile
January 26, 2020, 10:56:09 AM
Merited by fillippone (2), ETFbitcoin (1), Husna QA (1)
 #32

Looking at the title of BIP 341 (Taproot: SegWit version 1 spending rules), does that mean we'll see address with prefix bc1p?

yes. in a Bech32 encoding when you set the witness version to 1 the first character after the separator (ie. 1) is going to become letter "p".
BIP 173 doesn't mention this but it is easy to use one of the libraries to encode an arbitrary length byte array to see what the first character is. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
empty 32 bytes= bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq5us4ke

figmentofmyass
Legendary
*
Offline Offline

Activity: 1652
Merit: 1480



View Profile
January 27, 2020, 08:39:19 PM
 #33

has there been discussion about cross-input aggregation and when it might be implemented? i was under the (apparently mistaken) impression it was gonna be included with taproot. it does not appear to be included anywhere in BIP 340-342.

o_e_l_e_o
Legendary
*
Offline Offline

Activity: 1330
Merit: 6295


Wear a mask, slow the spread


View Profile
January 27, 2020, 09:16:24 PM
Merited by fillippone (2)
 #34

It's mentioned in BIP 341 as essentially not being ready yet:
Quote
Combining all these ideas in a single proposal would be an extensive change, be hard to review, and likely miss new discoveries that otherwise could have been made along the way. Not all are equally mature as well. For example, cross-input aggregation interacts in complex ways with upgrade mechanisms, and solutions to that are still in flux.


gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
January 28, 2020, 05:56:13 AM
Merited by Welsh (15), suchmoon (7), fillippone (5), Foxpup (4), ETFbitcoin (3), figmentofmyass (2), Husna QA (1), Waldschrat2 (1)
 #35

The main problem for cross input aggregation is that normally you can just soft-fork in new signature types (e.g. including new sighash types) just by creating a new checksig operator (or having a pubkey of a different length).

But a new signature type added in a backwards compatible softfork couldn't be aggregated with other signatures even if the underlying crypto is the same.  This is especially relevant because there is a current interest in adding some new sighash types, also graftroot which is also effectively a new sighash type.

Aggregation could have been done for basic taproot alone, and then any new types would have to be separately aggregated... but probably along the way we'd come up with different optimizations in how aggregation works, and then the consensus rules would have two implementations of aggregation. Worse, if taproot originally has aggregation people will probably upgrade slowly to a later tapgraftroot since mixed transactions would have higher overhead from the inability to aggregate them both, and fungibility would be hurt by the slow upgrade.

There are also some ideas that could allow for better backwards compatibility.  In particular,  if a new witness-like p2p extension were made that allowed transmitting the concrete sighash values as witness data to old nodes that don't know how to generate those sighashes (but otherwise not keep them in blocks),  then aggregation could be preserved even with future softforked in sig hashes.   But witness-like p2p extensions are a real pain to design and deploy, and no one seemed particularly eager to do that work right now. If one is done it should probably pick up some other improvements other than just backwards compatible aggregation.

So essentially, aggregation is conceptually ready but there are very strong incentives to deploy it in combination with other features which are not currently ready.  Trying to do everything at once is just too big an engineering project to pull off safely, and we're likely to learn a lot from actual usage of taproot which would help improve the design of other features (particularly of graftroot/g'root).

Right now I don't think the current amount of engineering interest in Bitcoin is particularly healthy.  Many long time contributors, including myself, have essentially stopped contributing for a variety of reasons (including uncertainty around political disruption of deploying even fairly boring new consensus changes, concern that too much bitcoin hashpower is controlled by bitcoin adversarial parties who would attempt to block protocol improvements, etc. on top of more generic factors).  Lightning is also easier, faster, and often more interesting to work on and so it has diverted a lot of new blood.
pereira4
Legendary
*
Offline Offline

Activity: 1610
Merit: 1177


View Profile
January 28, 2020, 01:27:31 PM
 #36

How far are we from rendering efforts like "chainanalysis" useless?

Every single wallet should be sending transactions that by default obfuscate things so no one is liable of this bullshit idea of having "tainted coins", in other words, actual fungibility.

obviously, schnorr signatures are on deck. that'll allow for cross-input aggregation to make coinjoins indistinguishable from regular transactions. that's a pretty massive development given that exchanges are beginning to target coinjoin users. estimating based on segwit's activation timeline, that could happen by early 2021 or maybe even the end of this year, optimistically.

but "useless"? that's quite a strong word. Lips sealed

confidential transactions (CT) to obfuscate transaction amounts seems like an attractive next step. but my understanding is it requires extension blocks or a hard fork. so.....probably not gonna be implemented at the consensus layer. there's always sidechains though. liquid (blockstream's sidechain) supports CT for example.

These things have to run at layer 0 to get any traction imo. We should have had better fungibility since day 1. Things should be mixed by default, what should be optional is making a clear A to B transaction. If we are going to have privacy, we want it to be as close to default state as possible. The internet went throught this already. We would have avoided the spying clusterfuck that it has become if it ran private by default. Only now ages later Tor is becoming more known as well as VPNs, but thats far from ideal. It's still nothing in the grand scheme of things.

Looking at the title of BIP 341 (Taproot: SegWit version 1 spending rules), does that mean we'll see address with prefix bc1p?

yes. in a Bech32 encoding when you set the witness version to 1 the first character after the separator (ie. 1) is going to become letter "p".
BIP 173 doesn't mention this but it is easy to use one of the libraries to encode an arbitrary length byte array to see what the first character is. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
empty 32 bytes= bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq5us4ke

Can't regular bech32 addresses begin with a p?
bulminer
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
January 28, 2020, 01:38:32 PM
 #37

Right now I don't think the current amount of engineering interest in Bitcoin is particularly healthy.  Many long time contributors, including myself, have essentially stopped contributing for a variety of reasons (including uncertainty around political disruption of deploying even fairly boring new consensus changes, concern that too much bitcoin hashpower is controlled by bitcoin adversarial parties who would attempt to block protocol improvements, etc. on top of more generic factors).  Lightning is also easier, faster, and often more interesting to work on and so it has diverted a lot of new blood.

The bips 340 341 and 342 if there is in the community a large consensus for their implementation, will in my opinion be one of the most important upgrades to Bitcoin. However, this implementation will also be a test of the community and its future, because if Bitcoin was already advertised by governments as a facilitation of money laundering, as well as the financing of criminal and terrorist organizations, with this upgrade, we will see strong attacks by political power.

Regarding to the hashpower, the new stratum v2 protocol, aims to further decentralization and break, in part, with the pools decision-making regarding to block protocol improvements.
pooya87
Legendary
*
Offline Offline

Activity: 2394
Merit: 3931


Remember tonight for it's the beginning of forever


View Profile
January 28, 2020, 01:53:52 PM
 #38

Can't regular bech32 addresses begin with a p?

I don't know what you have in mind when you say "regular address".
Bech-32 encoding is a rather simple encoding of any data that takes an octet string (8 bits) convert it to 5 bit chunks and then converts each chunk to one of 32 characters defined by BIP-173 (that is qpzry9x8gf2tvdw0s3jn54khce6mua7l).
For an address we add the witness version as its first 5-bit chunk without needing any conversion so when it is 0 you choose the first char that is "q" and when it is 1 you choose the second that is "p" and so on.
they are all "regular addresses" with a different version.

pereira4
Legendary
*
Offline Offline

Activity: 1610
Merit: 1177


View Profile
January 28, 2020, 02:08:57 PM
Last edit: January 28, 2020, 03:45:53 PM by pereira4
Merited by fillippone (2)
 #39

Can't regular bech32 addresses begin with a p?

I don't know what you have in mind when you say "regular address".
Bech-32 encoding is a rather simple encoding of any data that takes an octet string (8 bits) convert it to 5 bit chunks and then converts each chunk to one of 32 characters defined by BIP-173 (that is qpzry9x8gf2tvdw0s3jn54khce6mua7l).
For an address we add the witness version as its first 5-bit chunk without needing any conversion so when it is 0 you choose the first char that is "q" and when it is 1 you choose the second that is "p" and so on.
they are all "regular addresses" with a different version.

By regular I meant what you point to be as bc1q. So bc1p is it for the new one. I didn't realize it was bc1q, but bc1 then random string. Im not a segwit user myself, still only use legacy. There's no way in hell the regular average joe user will notice any of these changes. That's why I insist: we need everything to be "mixed by default" somehow, and optional would be the clear transactions, ideally. What I mean is, the end user should just have to click "send" and that would be by default a mixed transaction. Then have some box you can check to not mix it optionally. This would be the standardized functionality of all wallets. That's how we reach proper fungibility. Otherwise we are going to start seeing horror stories regarding chainanalysis and innocent people ending up with BTC that was "tainted" attached to their names when they deposit in exchanges and whatnot. The only way to avoid this is that everyone by default mixes coins.

figmentofmyass
Legendary
*
Offline Offline

Activity: 1652
Merit: 1480



View Profile
January 28, 2020, 10:29:39 PM
Merited by Welsh (2), fillippone (2), ETFbitcoin (1)
 #40

obviously, schnorr signatures are on deck. that'll allow for cross-input aggregation to make coinjoins indistinguishable from regular transactions. that's a pretty massive development given that exchanges are beginning to target coinjoin users. estimating based on segwit's activation timeline, that could happen by early 2021 or maybe even the end of this year, optimistically.

but "useless"? that's quite a strong word. Lips sealed

confidential transactions (CT) to obfuscate transaction amounts seems like an attractive next step. but my understanding is it requires extension blocks or a hard fork. so.....probably not gonna be implemented at the consensus layer. there's always sidechains though. liquid (blockstream's sidechain) supports CT for example.

These things have to run at layer 0 to get any traction imo.

taproot/schnorr will run at layer 0. CT could in theory too but there are strong reasons it won't (bloat and lack of support for consensus change).

We should have had better fungibility since day 1. Things should be mixed by default, what should be optional is making a clear A to B transaction. If we are going to have privacy, we want it to be as close to default state as possible.

taproot offers the beginnings of that. amounts and output linkability are still unaddressed at this time, but basically everything under the hood of a transaction can be hidden. cross-input aggregation (once implemented) will further provide strong fee incentives to drive users towards schnorr-based coinjoin and/or adaptor signature-based mixing transactions. wallets could offer these as automatic/default mechanisms. if most of the network is using taproot, these are pretty huge privacy gains for everyone.

unfortunately, we can't approach this issue as if it were day 1. as gmaxwell pointed out, there is uncertainty around being able to deploy even mundane consensus changes---let alone ones that are actually contentious.

pereira4
Legendary
*
Offline Offline

Activity: 1610
Merit: 1177


View Profile
February 03, 2020, 01:50:51 PM
 #41

obviously, schnorr signatures are on deck. that'll allow for cross-input aggregation to make coinjoins indistinguishable from regular transactions. that's a pretty massive development given that exchanges are beginning to target coinjoin users. estimating based on segwit's activation timeline, that could happen by early 2021 or maybe even the end of this year, optimistically.

but "useless"? that's quite a strong word. Lips sealed

confidential transactions (CT) to obfuscate transaction amounts seems like an attractive next step. but my understanding is it requires extension blocks or a hard fork. so.....probably not gonna be implemented at the consensus layer. there's always sidechains though. liquid (blockstream's sidechain) supports CT for example.

These things have to run at layer 0 to get any traction imo.

taproot/schnorr will run at layer 0. CT could in theory too but there are strong reasons it won't (bloat and lack of support for consensus change).

We should have had better fungibility since day 1. Things should be mixed by default, what should be optional is making a clear A to B transaction. If we are going to have privacy, we want it to be as close to default state as possible.

taproot offers the beginnings of that. amounts and output linkability are still unaddressed at this time, but basically everything under the hood of a transaction can be hidden. cross-input aggregation (once implemented) will further provide strong fee incentives to drive users towards schnorr-based coinjoin and/or adaptor signature-based mixing transactions. wallets could offer these as automatic/default mechanisms. if most of the network is using taproot, these are pretty huge privacy gains for everyone.

unfortunately, we can't approach this issue as if it were day 1. as gmaxwell pointed out, there is uncertainty around being able to deploy even mundane consensus changes---let alone ones that are actually contentious.

What will be interesting to see is how exchanges and businesses react to this, as well as governments. The only reason governments are allowing Bitcoin to stay legal, or even neutral, is due the fact that they think they have the means to control it with efforts such as chainanalysis. Once/if BTC reached a point of actual fungibility in which the costs of trying something like chainanalysis are bigger than simply outlawing it, that is what I would predict would happen (that governments outlaw it and go into a full front attack), which will only make other governments become tax havens for BTC holders. Ultimately the price would most likely be pushed upwards but there would be an awkward period of, once again, "Bitcoin is dead" all over mainstream media.
fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
February 03, 2020, 02:46:24 PM
 #42


What will be interesting to see is how exchanges and businesses react to this, as well as governments. The only reason governments are allowing Bitcoin to stay legal, or even neutral, is due the fact that they think they have the means to control it with efforts such as chainanalysis. Once/if BTC reached a point of actual fungibility in which the costs of trying something like chainanalysis are bigger than simply outlawing it, that is what I would predict would happen (that governments outlaw it and go into a full front attack), which will only make other governments become tax havens for BTC holders. Ultimately the price would most likely be pushed upwards but there would be an awkward period of, once again, "Bitcoin is dead" all over mainstream media.

I think it is worth noting that chainanalysis is based on very weak heutistics.
The reality is there is nothing linking an address to another one. (taking to the extreme, even a transaction with one input and one output).  And each steps those heuristics become weaker and weaker every step down the chain analysis.
 
I am afraid the "chainanalysis stuff" is nothing would hold in a serious trial.

By the way batch transactions (output aggregation) togheter with coinjoin (input + output aggregation) are the best practices to transact over the bitcoin protocol. The fact that these techniques aren't implemented in "basic" wallets is not relevant. Everyone should always transact this way for every of his transaction.



figmentofmyass
Legendary
*
Offline Offline

Activity: 1652
Merit: 1480



View Profile
February 03, 2020, 06:58:09 PM
 #43

I think it is worth noting that chainanalysis is based on very weak heutistics.
The reality is there is nothing linking an address to another one. (taking to the extreme, even a transaction with one input and one output).  And each steps those heuristics become weaker and weaker every step down the chain analysis.

indeed, there are layers upon layers of deniability baked in. there are other privacy pitfalls that could play a role, like browser/cookie analysis and IP address/bloom filter analysis by adversarial nodes. even then, the notion of getting a jury to convict based on this kind of chain of evidence is a tossup at best. blockchain analysis companies are generally working off a huge number of assumptions and that will become obvious to any jurors studying their protocols.
 
By the way batch transactions (output aggregation) togheter with coinjoin (input + output aggregation) are the best practices to transact over the bitcoin protocol. The fact that these techniques aren't implemented in "basic" wallets is not relevant. Everyone should always transact this way for every of his transaction.

in theory (actually this is arguable since coinjoin transactions are always currently more expensive).

in practice, most coinjoins are very obvious on-chain, and some exchange customers are paying the price for it. taproot, cross-input aggregation, and less obvious coinjoin mechanisms will mitigate this in the future, but for now all i can say is, be careful of your proximity to exchanges and AML/KYC enforcing services when engaging in coinjoins.

fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
February 03, 2020, 07:10:32 PM
 #44


in theory. in practice, most coinjoins are very obvious on-chain, and some exchange customers are paying the price for it. taproot, cross-input aggregation, and less obvious coinjoin mechanisms will mitigate this in the future, but for now all i can say is, be careful of your proximity to exchanges and AML/KYC enforcing services when engaging in coinjoins.

When an exchange harms your privacy applying weird heuristic to your transaction before or (worst) after using them, just stop using it.
I started a thread on this exact fact: [PAXOS+COINJOIN]Your privacy is a threat to exchange business?#deletepaxos

figmentofmyass
Legendary
*
Offline Offline

Activity: 1652
Merit: 1480



View Profile
February 03, 2020, 07:42:47 PM
 #45

in theory. in practice, most coinjoins are very obvious on-chain, and some exchange customers are paying the price for it. taproot, cross-input aggregation, and less obvious coinjoin mechanisms will mitigate this in the future, but for now all i can say is, be careful of your proximity to exchanges and AML/KYC enforcing services when engaging in coinjoins.
When an exchange harms your privacy applying weird heuristic to your transaction before or (worst) after using them, just stop using it.
I started a thread on this exact fact: [PAXOS+COINJOIN]Your privacy is a threat to exchange business?#deletepaxos

people should absolutely "vote with their money" and leave such exchanges, if that's a viable option for them.

that doesn't address the larger issue though. we need to consider what people actually do by default. think about why the maker/taker fee model is so prevalent: because the vast majority of market participants are liquidity takers. further, there is zero indication that privacy is a priority for most of them. they will continue seeking out the highest liquidity exchanges, who all seem to be ratcheting up their AML standards one by one.

so while i agree with you, i don't think that's a viable solution long term. privacy advocates will just have less and less services at their disposal, with worse and worse liquidity. what we need are better coinjoin solutions so that we can slip through unnoticed with the the rest of the masses---so we aren't at a constant disadvantage re liquidity. this will take some time.....probably years.

wasabi wallet was groundbreaking as a first step, but its coinjoin implementation obviously puts its users at a great disadvantage re existing blockchain analysis heuristics. that's a problem we can't afford to ignore.

fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
August 19, 2020, 10:29:25 AM
Merited by gmaxwell (1)
 #46

Nice article by Aaron Van Wirdum to non-technically sum up all the recent development in Taproot and how  Payment Pools could be used as as Layer 1 scaling solutions and privacy feature.

I don't want to cross-post, so I am linking it here.

gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
August 19, 2020, 10:57:05 PM
 #47

Pieter has posted about changing BIP340 to us a different R tiebreaker: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018081.html

This is some signature algorithm behavioural minutia. Basically BIP340 did an unconventional thing because we believed it was faster enough to be worth a small increase in implementation complexity but it turns out that our belief was based on a both a broken benchmark and a supporting (wrong) assumption and it's not actually faster and might, in fact, be slightly slower in the long run.  Changing to the more conventional thing would simplify implementations and make them somewhat faster.

He tells me that he's received a bunch of positive commentary on it, so I expect the change will be made soon!


gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
September 01, 2020, 01:18:29 AM
 #48

The above mentioned improvements have been applied and now the BIP340 support for libsecp256k1 is ready to be merged: https://twitter.com/pwuille/status/1300572711312265218
DooMAD
Legendary
*
Online Online

Activity: 2730
Merit: 1817


Leave no FUD unchallenged


View Profile WWW
September 05, 2020, 11:14:47 AM
 #49

The above mentioned improvements have been applied and now the BIP340 support for libsecp256k1 is ready to be merged: https://twitter.com/pwuille/status/1300572711312265218

Honestly thought this news deserved a little more attention than it seems to be getting.  A hardy "Good work!" to all involved.  Is the lack of fanfare purely because people are more excited about the aggregation part that isn't quite ready yet?

Carlton Banks
Legendary
*
Offline Offline

Activity: 3122
Merit: 2488



View Profile
September 14, 2020, 05:56:31 AM
Merited by fillippone (2), gmaxwell (1), ETFbitcoin (1), Wind_FURY (1)
 #50

it's now merged: https://github.com/bitcoin/bitcoin/pull/19944

Smiley

(and this is the secp256k1 subtree merged into the bitcoin core repository, it now looks that 0.21.1 will very likely include the taproot/schnorr activation code)

Vires in numeris
Wind_FURY
Legendary
*
Offline Offline

Activity: 1862
Merit: 1121


www.Crypto.Games: Multiple coins, multiple games


View Profile
September 15, 2020, 11:18:49 AM
 #51

it's now merged: https://github.com/bitcoin/bitcoin/pull/19944

Smiley

(and this is the secp256k1 subtree merged into the bitcoin core repository, it now looks that 0.21.1 will very likely include the taproot/schnorr activation code)


There's no drama from the trolls/big-blockers so far. Here's to hoping that this is activated as smoothly, and quickly as possible. Onward!

████  ███████  ███
██████████
███      ███████
███      ███████████
██████████████████
████████
███   ████  ███████████
███ ███████████████
█████████
█████████████████
███  ███████
██████████████
███        ████████
███████████▀▀███▀▀███████████
██████▀▀     ███     ▀▀██████
████▀   ▄▄█████████▄▄   ▀████
████▄▄▄███▀  ▀█▀  ▀███▄▄▄████
██▀▀▀██▀      ▀      ▀██▀▀▀██
█▀  ▄██               ██▄  ▀█
█   ████▄▄         ▄▄████   █
█▄  ▀██▀             ▀██▀  ▄█
██▄▄▄██▄             ▄██▄▄▄██
████▀▀▀███▄ ▄█ █▄ ▄███▀▀▀████
████▄   ▀▀███▄█████▀▀   ▄████
███████▄     ███     ▄███████
███████████▄▄███▄▄███████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
..PLAY NOW..
███  ███████  ████
██████████
███████      ███
███████████      ███
██████████████████
████████
███████████  ████   ███
███████████████ ███
█████████
█████████████████
███████  ███
██████████████
████████        ███
DooMAD
Legendary
*
Online Online

Activity: 2730
Merit: 1817


Leave no FUD unchallenged


View Profile WWW
September 15, 2020, 03:36:46 PM
Merited by gmaxwell (2)
 #52

There's no drama from the trolls/big-blockers so far.

I wasn't expecting any.  It's not particularly controversial and there aren't really any coherent arguments to be made against it.

Carlton Banks
Legendary
*
Offline Offline

Activity: 3122
Merit: 2488



View Profile
September 18, 2020, 03:47:22 PM
 #53


we may well see some


The most important point:

taproot only hides things that do not even happen. The script that is executed always appears on the blockchain when BTC is sent from a taproot address


stick to that argument, i say

(the troll reply is obvious: "no, the taproot secret script is encrypted with SHA256, not even Einstein and Hawking together could crack it and tell what's in the secret script. and money launderers, and Kazakh warlord gangsters. and people smoking Tide pods". Or something to that effect)

Vires in numeris
Carlton Banks
Legendary
*
Offline Offline

Activity: 3122
Merit: 2488



View Profile
September 18, 2020, 04:00:06 PM
 #54

we also have a new BIP 340-342 pull request to github.com/bitcoin/bitcoin (which makes small adjustments to the older pr): https://github.com/bitcoin/bitcoin/pull/19953

positive comments are accumulating already, the case for taproot activation code in 0.21.1 just became that little bit more promising Cool

Vires in numeris
Carlton Banks
Legendary
*
Offline Offline

Activity: 3122
Merit: 2488



View Profile
October 15, 2020, 08:58:47 AM
Merited by gmaxwell (1), Karartma1 (1), Wind_FURY (1)
 #55

we also have a new BIP 340-342 pull request to github.com/bitcoin/bitcoin (which makes small adjustments to the older pr): https://github.com/bitcoin/bitcoin/pull/19953

it's now merged Cool

the schnorr/taproot code will be in 0.21.0, so it's almost certain that activation parameters will be released as a part of 0.21.1 Smiley

Vires in numeris
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
October 15, 2020, 11:05:57 AM
Merited by Wind_FURY (1), darosior (1)
 #56

the schnorr/taproot code will be in 0.21.0, so it's almost certain that activation parameters will be released as a part of 0.21.1 Smiley
That would be really cool, but I dunno that it's almost certain.  One thing you can be certain of is that they'll be ready when they're released.
Karartma1
Legendary
*
Offline Offline

Activity: 2240
Merit: 1377


Be Revolutionary or Die Trying


View Profile WWW
October 15, 2020, 01:13:58 PM
 #57

So let me see if I got this right: after Taproot is activated will it be possible to know if a payment is the opening/closing/mutual closing of LN channel? As far as I understand this, it will be impossible to distinguish if such payment is, let's say, me opening a LN channel. Which is cool.
Right?

.freebitcoin.       ▄▄▄█▀▀██▄▄▄
   ▄▄██████▄▄█  █▀▀█▄▄
  ███  █▀▀███████▄▄██▀
   ▀▀▀██▄▄█  ████▀▀  ▄██
▄███▄▄  ▀▀▀▀▀▀▀  ▄▄██████
██▀▀█████▄     ▄██▀█ ▀▀██
██▄▄███▀▀██   ███▀ ▄▄  ▀█
███████▄▄███ ███▄▄ ▀▀▄  █
██▀▀████████ █████  █▀▄██
 █▄▄████████ █████   ███
  ▀████  ███ ████▄▄███▀
     ▀▀████   ████▀▀
BITCOIN
DICE
EVENT
BETTING
WIN A LAMBO !

.
            ▄▄▄▄▄▄▄▄▄▄███████████▄▄▄▄▄
▄▄▄▄▄██████████████████████████████████▄▄▄▄
▀██████████████████████████████████████████████▄▄▄
▄▄████▄█████▄████████████████████████████▄█████▄████▄▄
▀████████▀▀▀████████████████████████████████▀▀▀██████████▄
  ▀▀▀████▄▄▄███████████████████████████████▄▄▄██████████
       ▀█████▀  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  ▀█████▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.PLAY NOW.
Wind_FURY
Legendary
*
Offline Offline

Activity: 1862
Merit: 1121


www.Crypto.Games: Multiple coins, multiple games


View Profile
October 16, 2020, 06:10:51 AM
 #58

we also have a new BIP 340-342 pull request to github.com/bitcoin/bitcoin (which makes small adjustments to the older pr): https://github.com/bitcoin/bitcoin/pull/19953

it's now merged Cool

the schnorr/taproot code will be in 0.21.0, so it's almost certain that activation parameters will be released as a part of 0.21.1 Smiley

This might be another big trial for the network and its participants after the scaling debate in my opinion. Let's wait, and see if some entities from the mining-cartel play nice.

████  ███████  ███
██████████
███      ███████
███      ███████████
██████████████████
████████
███   ████  ███████████
███ ███████████████
█████████
█████████████████
███  ███████
██████████████
███        ████████
███████████▀▀███▀▀███████████
██████▀▀     ███     ▀▀██████
████▀   ▄▄█████████▄▄   ▀████
████▄▄▄███▀  ▀█▀  ▀███▄▄▄████
██▀▀▀██▀      ▀      ▀██▀▀▀██
█▀  ▄██               ██▄  ▀█
█   ████▄▄         ▄▄████   █
█▄  ▀██▀             ▀██▀  ▄█
██▄▄▄██▄             ▄██▄▄▄██
████▀▀▀███▄ ▄█ █▄ ▄███▀▀▀████
████▄   ▀▀███▄█████▀▀   ▄████
███████▄     ███     ▄███████
███████████▄▄███▄▄███████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
..PLAY NOW..
███  ███████  ████
██████████
███████      ███
███████████      ███
██████████████████
████████
███████████  ████   ███
███████████████ ███
█████████
█████████████████
███████  ███
██████████████
████████        ███
Carlton Banks
Legendary
*
Offline Offline

Activity: 3122
Merit: 2488



View Profile
October 16, 2020, 09:00:13 AM
Merited by fillippone (2), ETFbitcoin (1)
 #59

This might be another big trial for the network and its participants after the scaling debate in my opinion. Let's wait, and see if some entities from the mining-cartel play nice.

no-one's voiced any objections up to now. You keep saying it's going to be a problem though, like maybe 5 times already?


why would anyone care about a new scripting type that prevents choices in those scripts from being written to the blockchain?

  • everything that _actually_ happens is written to the blockchain, for all to see
  • everything that _does not_ happen is unrecorded

I'd be fascinated to hear the arguments that could possibly be mounted against excising unused script paths from transactions, all it does is make multi-path scripts more economical. Secondary effects of this don't change the fact that the chosen script path is still publicly available.




ot: You're very negative/pessimistic these days WindFURY, are you feeling ok?

Vires in numeris
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1904
Merit: 2821


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
October 16, 2020, 11:25:00 AM
 #60

we also have a new BIP 340-342 pull request to github.com/bitcoin/bitcoin (which makes small adjustments to the older pr): https://github.com/bitcoin/bitcoin/pull/19953

it's now merged Cool

the schnorr/taproot code will be in 0.21.0, so it's almost certain that activation parameters will be released as a part of 0.21.1 Smiley

This might be another big trial for the network and its participants after the scaling debate in my opinion. Let's wait, and see if some entities from the mining-cartel play nice.

You really like drama and/or conflict, don't you? Unlike SegWit and various idea to increase block size (e.g. BIP 100-109), there are very few discussion, article or news which oppose Taproot and it's derivative (e.g. Schnorr and SegWit version 1/a.k.a bc1p).

The "worst" i could remember are these 3 mailing which is quite civil:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017615.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017616.html

DooMAD
Legendary
*
Online Online

Activity: 2730
Merit: 1817


Leave no FUD unchallenged


View Profile WWW
October 16, 2020, 01:10:50 PM
Last edit: October 20, 2020, 11:04:35 AM by DooMAD
 #61

This might be another big trial for the network and its participants after the scaling debate in my opinion. Let's wait, and see if some entities from the mining-cartel play nice.

I suppose, given the lengths certain trolls are prepared to go to in causing drama, it's easy to get paranoid about this sort of thing.  But honestly, it would be too obvious they were clutching at straws if they tried to oppose such an obviously beneficial change.  Playing devil's advocate, what argument against it would you expect them to give?  I can't think of any downsides.

Miners, I figure, would be indifferent at worst.  There are no negative impacts on them that I'm aware of.  If anything, once aggregation is implemented later, it potentially allows them to earn a tiny fraction more in fees if we're making more efficient use of space within blocks and can occasionally squeeze in a few more transactions.

darosior
Sr. Member
****
Offline Offline

Activity: 279
Merit: 431



View Profile WWW
October 16, 2020, 11:11:52 PM
Merited by Carlton Banks (1), JayJuanGee (1), ETFbitcoin (1)
 #62

Now the implementation is merged into the reference client, activation discussions slowly restarted on IRC (`##taproot-activation` on freenode).
Here is a wiki page (thanks to David Harding) summing up the "main" different activation methods proposed so far, as well as a rationale and pros / cons for each of them.

Github profile ~ GPG key: 590B7292695AFFA5B672CBB2E13FC145CD3F4304
Wind_FURY
Legendary
*
Offline Offline

Activity: 1862
Merit: 1121


www.Crypto.Games: Multiple coins, multiple games


View Profile
October 17, 2020, 04:29:41 AM
 #63

This might be another big trial for the network and its participants after the scaling debate in my opinion. Let's wait, and see if some entities from the mining-cartel play nice.

no-one's voiced any objections up to now. You keep saying it's going to be a problem though, like maybe 5 times already?


why would anyone care about a new scripting type that prevents choices in those scripts from being written to the blockchain?

  • everything that _actually_ happens is written to the blockchain, for all to see
  • everything that _does not_ happen is unrecorded

I'd be fascinated to hear the arguments that could possibly be mounted against excising unused script paths from transactions, all it does is make multi-path scripts more economical. Secondary effects of this don't change the fact that the chosen script path is still publicly available.




ot: You're very negative/pessimistic these days WindFURY, are you feeling ok?


I'm never pessimistic about Bitcoin, but I don't trust the mining-cartel.

Or maybe I'm just excited for another drama, and proved right that full nodes control the consensus rules, not the miners. Cool

Now the implementation is merged into the reference client, activation discussions slowly restarted on IRC (`##taproot-activation` on freenode).
Here is a wiki page (thanks to David Harding) summing up the "main" different activation methods proposed so far, as well as a rationale and pros / cons for each of them.


What are the miners proposing? Cool

████  ███████  ███
██████████
███      ███████
███      ███████████
██████████████████
████████
███   ████  ███████████
███ ███████████████
█████████
█████████████████
███  ███████
██████████████
███        ████████
███████████▀▀███▀▀███████████
██████▀▀     ███     ▀▀██████
████▀   ▄▄█████████▄▄   ▀████
████▄▄▄███▀  ▀█▀  ▀███▄▄▄████
██▀▀▀██▀      ▀      ▀██▀▀▀██
█▀  ▄██               ██▄  ▀█
█   ████▄▄         ▄▄████   █
█▄  ▀██▀             ▀██▀  ▄█
██▄▄▄██▄             ▄██▄▄▄██
████▀▀▀███▄ ▄█ █▄ ▄███▀▀▀████
████▄   ▀▀███▄█████▀▀   ▄████
███████▄     ███     ▄███████
███████████▄▄███▄▄███████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
..PLAY NOW..
███  ███████  ████
██████████
███████      ███
███████████      ███
██████████████████
████████
███████████  ████   ███
███████████████ ███
█████████
█████████████████
███████  ███
██████████████
████████        ███
Karartma1
Legendary
*
Offline Offline

Activity: 2240
Merit: 1377


Be Revolutionary or Die Trying


View Profile WWW
October 17, 2020, 08:11:48 AM
 #64

Now the implementation is merged into the reference client, activation discussions slowly restarted on IRC (`##taproot-activation` on freenode).
Here is a wiki page (thanks to David Harding) summing up the "main" different activation methods proposed so far, as well as a rationale and pros / cons for each of them.
Let's see what happens has a truly encouraging name  Grin
Anyway, I asked this before and it would be nice to have an answer to see whether I got it right or not.
So let me see if I got this right: after Taproot is activated will it be possible to know if a payment is the opening/closing/mutual closing of LN channel? As far as I understand this, it will be impossible to distinguish if such payment is, let's say, me opening a LN channel. Which is cool.
Right?
Thanks

.freebitcoin.       ▄▄▄█▀▀██▄▄▄
   ▄▄██████▄▄█  █▀▀█▄▄
  ███  █▀▀███████▄▄██▀
   ▀▀▀██▄▄█  ████▀▀  ▄██
▄███▄▄  ▀▀▀▀▀▀▀  ▄▄██████
██▀▀█████▄     ▄██▀█ ▀▀██
██▄▄███▀▀██   ███▀ ▄▄  ▀█
███████▄▄███ ███▄▄ ▀▀▄  █
██▀▀████████ █████  █▀▄██
 █▄▄████████ █████   ███
  ▀████  ███ ████▄▄███▀
     ▀▀████   ████▀▀
BITCOIN
DICE
EVENT
BETTING
WIN A LAMBO !

.
            ▄▄▄▄▄▄▄▄▄▄███████████▄▄▄▄▄
▄▄▄▄▄██████████████████████████████████▄▄▄▄
▀██████████████████████████████████████████████▄▄▄
▄▄████▄█████▄████████████████████████████▄█████▄████▄▄
▀████████▀▀▀████████████████████████████████▀▀▀██████████▄
  ▀▀▀████▄▄▄███████████████████████████████▄▄▄██████████
       ▀█████▀  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  ▀█████▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.PLAY NOW.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
October 17, 2020, 10:21:46 AM
 #65

I believe you will only be able to distinguish the lightning transactions if they are non-cooperative.  Openings and cooperative closures should be indistinguishable from ordinary single key payments.

[I say I believe because I'm not super well versed in lightning details, but this is indeed the idea.]
Karartma1
Legendary
*
Offline Offline

Activity: 2240
Merit: 1377


Be Revolutionary or Die Trying


View Profile WWW
October 17, 2020, 12:35:13 PM
 #66

I believe you will only be able to distinguish the lightning transactions if they are non-cooperative.  Openings and cooperative closures should be indistinguishable from ordinary single key payments.

[I say I believe because I'm not super well versed in lightning details, but this is indeed the idea.]
Ok, cool. I will look into it more. However, the simple fact that openings and cooperative closures will be indistinguishable from ordinary single key payments is great in my opinion. That's a very good step forward. Eagerly waiting for it.  Wink

.freebitcoin.       ▄▄▄█▀▀██▄▄▄
   ▄▄██████▄▄█  █▀▀█▄▄
  ███  █▀▀███████▄▄██▀
   ▀▀▀██▄▄█  ████▀▀  ▄██
▄███▄▄  ▀▀▀▀▀▀▀  ▄▄██████
██▀▀█████▄     ▄██▀█ ▀▀██
██▄▄███▀▀██   ███▀ ▄▄  ▀█
███████▄▄███ ███▄▄ ▀▀▄  █
██▀▀████████ █████  █▀▄██
 █▄▄████████ █████   ███
  ▀████  ███ ████▄▄███▀
     ▀▀████   ████▀▀
BITCOIN
DICE
EVENT
BETTING
WIN A LAMBO !

.
            ▄▄▄▄▄▄▄▄▄▄███████████▄▄▄▄▄
▄▄▄▄▄██████████████████████████████████▄▄▄▄
▀██████████████████████████████████████████████▄▄▄
▄▄████▄█████▄████████████████████████████▄█████▄████▄▄
▀████████▀▀▀████████████████████████████████▀▀▀██████████▄
  ▀▀▀████▄▄▄███████████████████████████████▄▄▄██████████
       ▀█████▀  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  ▀█████▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.PLAY NOW.
Charles-Tim
Hero Member
*****
Online Online

Activity: 490
Merit: 1218


Don't be a fool, paying 2 to get 4? It's a scam.


View Profile
October 19, 2020, 04:17:24 PM
Merited by JayJuanGee (1)
 #67

I want to add just a comment. Some people may be mistaking that Taproot will be able to make CoinJoin transactions harder to see, although, Taproots hide scripts and making multisig indistinguishable but it does not directly do anything for CoinJoin.” So, what I know for now about taproot is that it will make multisig transactions to look like single key transactions.

And I will like people to know that Bitcoin’s Taproot is ready now, only remaining it to be included in bitcoin core, but it's unlikely to be included in the next release. The Bitcoin Improvement Proposals 340 through 342 were merged into the Bitcoin codebase on Thursday, signaling that the anticipated Taproot upgrade is ready.

https://cointelegraph.com/news/bitcoin-s-taproot-is-ready-to-go-but-it-s-unlikely-to-be-included-in-the-next-release
https://cointelegraph.com/news/bitcoins-taproot-upgrade-wont-help-privacy-where-it-matters





BUY & SELL
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
BITCOIN ETHEREUM RIPPLE
FAQ
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
AFFILIATE PROGRAM




░██████████████████░
████████████████████
█████████▀░░░███████
█████████░░▄████████
███████▀▀░░▀▀███████
███████▄▄░░▄▄███████
█████████░░█████████

█████████░░█████████

█████████▄▄█████████

████████████████████

░██████████████████░
░██████████████████░
████████████████████
████████████▀▀▀█▀███
███░▀█████▀░░░░░▀███
███▌░░░▀▀▀░░░░░░████
████▄░░░░░░░░░░░████
█████▀░░░░░░░░░█████

██████▄░░░░░▄▄██████

█████▄▄▄▄███████████

████████████████████

░██████████████████░
░██████████████████░
████████████████████
████████████████████
███████████▀▀░░▐████
███████▀▀░░░░░█████
████▀░░░▄█▀░░░▐█████
█████▄▄█▀░░░░░██████

███████▌▄▄▄▐██████

████████████████████

████████████████████

░██████████████████░
Carlton Banks
Legendary
*
Offline Offline

Activity: 3122
Merit: 2488



View Profile
October 19, 2020, 07:37:25 PM
 #68

I want to add just a comment. Some people may be mistaking that Taproot will be able to make CoinJoin transactions harder to see, although, Taproots hide scripts and making multisig indistinguishable but it does not directly do anything for CoinJoin.

there will be no benefit to Coinjoins from BIPs 340-342. Originally, "cross-input signature aggregation" was vaunted to be included in the Schnorr implementation, but in the end was left out (to simplify the changeset IIRC). All that would have enabled is to make Coinjoins cheaper, they would be equally recognizable on-chain as they were before schnorr sigs


So, what I know for now about taproot is that it will make multisig transactions to look like single key transactions.

right, or anything using a hash-embedded script (including Lighting channels opens/closes)

this is why Coinjoins don't gain any privacy with Taproot, as a Coinjoin transaction is not script hash based

Vires in numeris
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
October 20, 2020, 12:40:39 AM
Merited by fillippone (2), JayJuanGee (1), ETFbitcoin (1)
 #69

I think that's not quite the case:  There is a privacy benefit in that single key, multisig, and channels will be less distinguishable, eventually improving the anonymity set for all transactions.  Specifically for coinjoins it means that you could have a single key and a multisig using party coinjoining and you couldn't distinguish them.

Though this is more of a long term benefit once the new style is the most common, initially privacy will be reduced somewhat through the proliferation of more address types.

You're absolutely right though that some people are confusing the aggregation benefits discussed previously with something taproot provides.
Karartma1
Legendary
*
Offline Offline

Activity: 2240
Merit: 1377


Be Revolutionary or Die Trying


View Profile WWW
October 20, 2020, 09:14:22 AM
 #70

I am writing it mostly to merge the content into my head......
  • Not all Bitcoin addresses and transactions are equal since we have different address types: addresses starting with “3” are scripts, meaning that they imply multiple keys or implement segregated witness
  • Taproot gets rid of the 1/3 address type distinction. As said before, all txs look just like regular transactions from one person to another, no matter how many people participated

Example: let's imagine a payment channel that Alice and Bob opened on the LN. Once they are done, they want to close the channel and take their BTC back. Before Taproot, the channel’s closure implies the creation of a bulky tx, which would reveal too much about what happened. Enter Taproot, this action between A&B would appear as a regular transaction distributing funds to Alice and Bob, as if a third-party had sent them coins.

Sounds cool to me

.freebitcoin.       ▄▄▄█▀▀██▄▄▄
   ▄▄██████▄▄█  █▀▀█▄▄
  ███  █▀▀███████▄▄██▀
   ▀▀▀██▄▄█  ████▀▀  ▄██
▄███▄▄  ▀▀▀▀▀▀▀  ▄▄██████
██▀▀█████▄     ▄██▀█ ▀▀██
██▄▄███▀▀██   ███▀ ▄▄  ▀█
███████▄▄███ ███▄▄ ▀▀▄  █
██▀▀████████ █████  █▀▄██
 █▄▄████████ █████   ███
  ▀████  ███ ████▄▄███▀
     ▀▀████   ████▀▀
BITCOIN
DICE
EVENT
BETTING
WIN A LAMBO !

.
            ▄▄▄▄▄▄▄▄▄▄███████████▄▄▄▄▄
▄▄▄▄▄██████████████████████████████████▄▄▄▄
▀██████████████████████████████████████████████▄▄▄
▄▄████▄█████▄████████████████████████████▄█████▄████▄▄
▀████████▀▀▀████████████████████████████████▀▀▀██████████▄
  ▀▀▀████▄▄▄███████████████████████████████▄▄▄██████████
       ▀█████▀  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  ▀█████▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.PLAY NOW.
Carlton Banks
Legendary
*
Offline Offline

Activity: 3122
Merit: 2488



View Profile
October 20, 2020, 12:11:44 PM
 #71

  • Not all Bitcoin addresses and transactions are equal since we have different address types: addresses starting with “3” are scripts, meaning that they imply multiple keys or implement segregated witness
  • Taproot gets rid of the 1/3 address type distinction. As said before, all txs look just like regular transactions from one person to another, no matter how many people participated

just to clarify, schnorr sigs are also needed to remove the distinction between single-sig and multi-sig, as signature aggregation (not possible with ECDSA sigs) reduces all the signatures from separate parties in a Multi-sig address to one (the signatures _are_ calculated separately, but the participants then literally add the signatures together to produce a single signature that validates the transaction)

without schnorr's sig-agg, multi-sig txs would still require the minimum quantity of sigs defined as the threshold minimum in the scriptSig, and more than one signatures necessarily means more than one signer Wink (unless you're using multi-sig as a security measure where you sign with 2+ devices, taproot/schnorr protects that kind of user from revealing their security practices also)


but yes, in essence, the net effect of BIPS 340-342 will remove the distinction between "script hash" addresses (beginning with a "1" character) and "public key hash" addresses (beginning with a "3" character). They will appear identical as addresses encoded on the blockchain, and when multisig is used with the typical scripting opcode sequence (1 input, 2 output, locktime set to current block at signing time). Because Lightning opens and co-operative closes are exactly that kind of transaction, they will also now look identical to these pedestrian tx types too (but not for Lightning uncooperative closes, which require a future locktime)

But atypical scripts will still be just as noticeably different as before, the only difference being that alternate paths (i.e. OP_OR sections within the script) will not be recorded to the blockchain, only the path that is actually used to spend the output from the address is written to chain.

Vires in numeris
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
October 20, 2020, 12:25:36 PM
Merited by Carlton Banks (2), ETFbitcoin (2), JayJuanGee (1), Husna QA (1)
 #72

just to clarify, schnorr sigs are also needed to remove the distinction between single-sig and multi-sig, as signature aggregation (not possible with ECDSA sigs) reduces all the signatures from separate parties in a Multi-sig address to one (the signatures _are_ calculated separately, but the participants then literally add the signatures together to produce a single signature that validates the transaction)

without schnorr's sig-agg, multi-sig txs would still require the minimum quantity of sigs defined as the threshold minimum in the scriptSig, and more than one signatures necessarily means more than one signer Wink (unless you're using multi-sig as a security measure where you sign with 2+ devices, taproot/schnorr protects that kind of user from revealing their security practices also)

Terminology danger!

Signature aggregation refers to the case where the verifier (the blockchain) knows a bunch of different pubkeys and you prove that they all approved a transaction using a single aggregated signature.  This is the often talked about thing that taproot doesn't include that would help make multi-input transactions much smaller.

Threshold signatures and _key_ aggregation are where some participants cooperate to produce a single key which some threshold of them can sign for, but which to the network just looks like a single party signing.  Taproot allows this, and it's what allows you to make multisig like usage which is indistinguishable from single key.

So taproot removes the distinction between single party spends and multisig too (which can include lightning input spends which don't actually use CSV/CLTV, even if they have it available).  Indistinguishable threshold signatures may not, however, be usable for all multisig usage because the threshold signature requires a little more interaction between signers and because in some cases you really want the public record to reflect which participants out of the threshold actually participated.

Quote
But atypical scripts will still be just as noticeably different as before, the only difference being that alternate paths (i.e. OP_OR sections within the script) will not be recorded to the blockchain, only the path that is actually used to spend the output from the address is written to chain.

Yes, but almost always you can restructure a script as "[All the parties agree]  OR [Complicated script thing]". If you can do this, you can put an N of N pubkey at the top, and if the parties cooperate, the parties can cooperate and just sign and and the fact that "complicated script thing" exists at all will not be exposed.

The only time the existence of a complicated script would be exposed is if some parties don't cooperate (E.g. because they're offline).
 
Karartma1
Legendary
*
Offline Offline

Activity: 2240
Merit: 1377


Be Revolutionary or Die Trying


View Profile WWW
October 20, 2020, 02:21:11 PM
 #73

So taproot removes the distinction between single party spends and multisig too (which can include lightning input spends which don't actually use CSV/CLTV, even if they have it available).  Indistinguishable threshold signatures may not, however, be usable for all multisig usage because the threshold signature requires a little more interaction between signers and because in some cases you really want the public record to reflect which participants out of the threshold actually participated.

Of course, and that's actually a very elegant way to put it. Thanks gmaxwell, keep contributing here for us to really get into all-bitcoin-tech-things. And, really, thank you both for your two posts as now I believe I have a much clearer picture regarding what Taproot activation would mean. Thank you so much!

.freebitcoin.       ▄▄▄█▀▀██▄▄▄
   ▄▄██████▄▄█  █▀▀█▄▄
  ███  █▀▀███████▄▄██▀
   ▀▀▀██▄▄█  ████▀▀  ▄██
▄███▄▄  ▀▀▀▀▀▀▀  ▄▄██████
██▀▀█████▄     ▄██▀█ ▀▀██
██▄▄███▀▀██   ███▀ ▄▄  ▀█
███████▄▄███ ███▄▄ ▀▀▄  █
██▀▀████████ █████  █▀▄██
 █▄▄████████ █████   ███
  ▀████  ███ ████▄▄███▀
     ▀▀████   ████▀▀
BITCOIN
DICE
EVENT
BETTING
WIN A LAMBO !

.
            ▄▄▄▄▄▄▄▄▄▄███████████▄▄▄▄▄
▄▄▄▄▄██████████████████████████████████▄▄▄▄
▀██████████████████████████████████████████████▄▄▄
▄▄████▄█████▄████████████████████████████▄█████▄████▄▄
▀████████▀▀▀████████████████████████████████▀▀▀██████████▄
  ▀▀▀████▄▄▄███████████████████████████████▄▄▄██████████
       ▀█████▀  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  ▀█████▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.PLAY NOW.
piotr_n
Legendary
*
Offline Offline

Activity: 2047
Merit: 1115


aka tonikt


View Profile WWW
October 21, 2020, 11:58:47 AM
 #74

Will there be any taproot related tests added to the src/test/data ?

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
October 21, 2020, 04:49:26 PM
Merited by piotr_n (1)
 #75

Will there be any taproot related tests added to the src/test/data ?
There are vectors at https://github.com/bitcoin/bitcoin/pull/19953/files#diff-6794e4c8edce5f4dd1a21181a91f0c166f34c876809e40f015e5926ee3d6a126
Wind_FURY
Legendary
*
Offline Offline

Activity: 1862
Merit: 1121


www.Crypto.Games: Multiple coins, multiple games


View Profile
October 23, 2020, 09:16:54 AM
 #76

I want to add just a comment. Some people may be mistaking that Taproot will be able to make CoinJoin transactions harder to see, although, Taproots hide scripts and making multisig indistinguishable but it does not directly do anything for CoinJoin.” So, what I know for now about taproot is that it will make multisig transactions to look like single key transactions.


Some Bitcoin tumblers and Wasabi/Samourai should start developing/testing, and see what they can build for "offchain mixing". I believe that could give a lot of users a very valid reason to start using Lightning.

████  ███████  ███
██████████
███      ███████
███      ███████████
██████████████████
████████
███   ████  ███████████
███ ███████████████
█████████
█████████████████
███  ███████
██████████████
███        ████████
███████████▀▀███▀▀███████████
██████▀▀     ███     ▀▀██████
████▀   ▄▄█████████▄▄   ▀████
████▄▄▄███▀  ▀█▀  ▀███▄▄▄████
██▀▀▀██▀      ▀      ▀██▀▀▀██
█▀  ▄██               ██▄  ▀█
█   ████▄▄         ▄▄████   █
█▄  ▀██▀             ▀██▀  ▄█
██▄▄▄██▄             ▄██▄▄▄██
████▀▀▀███▄ ▄█ █▄ ▄███▀▀▀████
████▄   ▀▀███▄█████▀▀   ▄████
███████▄     ███     ▄███████
███████████▄▄███▄▄███████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
..PLAY NOW..
███  ███████  ████
██████████
███████      ███
███████████      ███
██████████████████
████████
███████████  ████   ███
███████████████ ███
█████████
█████████████████
███████  ███
██████████████
████████        ███
piotr_n
Legendary
*
Offline Offline

Activity: 2047
Merit: 1115


aka tonikt


View Profile WWW
October 25, 2020, 12:32:11 PM
 #77


I only found test vectors in bip340_test_vectors.csv - but they seem to be only checking sign_schnorr() and verify_schnorr() functions.

Are there any new test for entire scripts and transactions?


Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
piotr_n
Legendary
*
Offline Offline

Activity: 2047
Merit: 1115


aka tonikt


View Profile WWW
October 25, 2020, 01:44:22 PM
 #78

Am I getting it wrong thinking that "schnorr" is just an improved way of doing EC signatures, while "taproot" is an extension to the scripts interpreter?

Because reading some publications (and this forum topic), one could get an impression that schnorr and taproot are synonyms, whilst for me they are two different features. Although, I understand that they are planned to be deployed and activated together.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
October 25, 2020, 02:54:47 PM
Last edit: October 25, 2020, 03:41:48 PM by gmaxwell
Merited by piotr_n (3), ETFbitcoin (2), fillippone (2), JayJuanGee (1)
 #79

Am I getting it wrong thinking that "schnorr" is just an improved way of doing EC signatures, while "taproot" is an extension to the scripts interpreter?

Because reading some publications (and this forum topic), one could get an impression that schnorr and taproot are synonyms, whilst for me they are two different features. Although, I understand that they are planned to be deployed and activated together.

Schnorr without taproot isn't really that useful: it makes it simpler and safer to write threshold signatures but that's it-- you can already threshold signatures using burdensomely complicated client software.  And threshold signatures by themselves don't even do that much-- they let you make signatures somewhat smaller but only when you don't need to be able to tell which parties signed.   It's better --- but perhaps not worth the trouble of a consensus change by itself.

Taproot without schnorr isn't really that useful: without threshold signatures, which are burdensomely complex to write software for without schnorr, it only lets you have a single party key at the top (which is pretty useless.)

There is a third logical part of taproot,  which is the merkelized script. This part is probably the most useful of the three on its own, but it's much more useful in combination.  With it you can use trees of N of Ns to make thresholds work usefully even when you need to be able to tell which parties signed, and  N of Ns are much easier to deal with than arbitrary thresholds, because the latter requires interactive secret key generation.

In order to have the property where arbitrary complex scripts are normally indistinguishable from one-of-one payments you need all three.  They also can't just be independently implemented: taproot changes the pubkey that goes into schnorr verification to commit to the merkelized script.

There were other techniques proposed, including graftroot (allows you to add scripts to an output after someone has already paid to it), and improved signature flags--  but those were possible to implement independently without leaving the rest not very useful.  There were also a number of next steps like signature aggregation which would have been best implemented in combination but were still left out because the three main features of the taproot bip were still useful without it.

I only found test vectors in bip340_test_vectors.csv - but they seem to be only checking sign_schnorr() and verify_schnorr() functions.
Are there any new test for entire scripts and transactions?
Looks like all the new testing is done with the python framework. I'll prod Pieter to add old style vectors.

They are over here: https://github.com/bitcoin-core/qa-assets/blob/master/unit_test_data/script_assets_test.json
Wind_FURY
Legendary
*
Offline Offline

Activity: 1862
Merit: 1121


www.Crypto.Games: Multiple coins, multiple games


View Profile
November 18, 2020, 06:37:24 AM
Merited by JayJuanGee (1)
 #80

There are three mining pools which have started to signal support for Taproot/Schnorr activation. Poolin, Slush, and BTC.com.

BTC.com? Isn't that Roger Ver's pool?

Tracker, https://taprootactivation.com/

████  ███████  ███
██████████
███      ███████
███      ███████████
██████████████████
████████
███   ████  ███████████
███ ███████████████
█████████
█████████████████
███  ███████
██████████████
███        ████████
███████████▀▀███▀▀███████████
██████▀▀     ███     ▀▀██████
████▀   ▄▄█████████▄▄   ▀████
████▄▄▄███▀  ▀█▀  ▀███▄▄▄████
██▀▀▀██▀      ▀      ▀██▀▀▀██
█▀  ▄██               ██▄  ▀█
█   ████▄▄         ▄▄████   █
█▄  ▀██▀             ▀██▀  ▄█
██▄▄▄██▄             ▄██▄▄▄██
████▀▀▀███▄ ▄█ █▄ ▄███▀▀▀████
████▄   ▀▀███▄█████▀▀   ▄████
███████▄     ███     ▄███████
███████████▄▄███▄▄███████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
..PLAY NOW..
███  ███████  ████
██████████
███████      ███
███████████      ███
██████████████████
████████
███████████  ████   ███
███████████████ ███
█████████
█████████████████
███████  ███
██████████████
████████        ███
Karartma1
Legendary
*
Offline Offline

Activity: 2240
Merit: 1377


Be Revolutionary or Die Trying


View Profile WWW
November 18, 2020, 07:49:33 AM
Merited by fillippone (2)
 #81

There are three mining pools which have started to signal support for Taproot/Schnorr activation. Poolin, Slush, and BTC.com.

BTC.com? Isn't that Roger Ver's pool?

Tracker, https://taprootactivation.com/
That's a small start: currently, those three pools contribute an overall of 25% of global hashing power. By the way, BTC.com is from Bitmain.
It's interesting to notice the already very different approaches of the first three pools signaling the upgrade:
  • Poolin - BIP9 (the same BIP for SegWit that went through tough times where the upgrade need to be activated before a specific time reaching a set threshold)
  • Slush Pool - BIP8 (UASF that would also activate the upgrade at a specific future date or block height no matter the threshold reached)
  • BTC.com - BIP8 + BIP9

Let's see when other pools join the party.

 

.freebitcoin.       ▄▄▄█▀▀██▄▄▄
   ▄▄██████▄▄█  █▀▀█▄▄
  ███  █▀▀███████▄▄██▀
   ▀▀▀██▄▄█  ████▀▀  ▄██
▄███▄▄  ▀▀▀▀▀▀▀  ▄▄██████
██▀▀█████▄     ▄██▀█ ▀▀██
██▄▄███▀▀██   ███▀ ▄▄  ▀█
███████▄▄███ ███▄▄ ▀▀▄  █
██▀▀████████ █████  █▀▄██
 █▄▄████████ █████   ███
  ▀████  ███ ████▄▄███▀
     ▀▀████   ████▀▀
BITCOIN
DICE
EVENT
BETTING
WIN A LAMBO !

.
            ▄▄▄▄▄▄▄▄▄▄███████████▄▄▄▄▄
▄▄▄▄▄██████████████████████████████████▄▄▄▄
▀██████████████████████████████████████████████▄▄▄
▄▄████▄█████▄████████████████████████████▄█████▄████▄▄
▀████████▀▀▀████████████████████████████████▀▀▀██████████▄
  ▀▀▀████▄▄▄███████████████████████████████▄▄▄██████████
       ▀█████▀  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  ▀█████▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.PLAY NOW.
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1904
Merit: 2821


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
November 18, 2020, 11:08:21 AM
Merited by fillippone (2)
 #82

That's a small start: currently, those three pools contribute an overall of 25% of global hashing power.

From another perspective 2 of them (Poolin & BTC.com) are 2nd & 3rd with biggest hashrate, which is good start IMO.

fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
November 18, 2020, 04:04:23 PM
 #83

 Another summary from BTC Times:

Mining Pools Poolin, Slush & BTC.com Announce Support for Taproot

Quote
According to Taproot-Activation, a website launched by Poolin, three large mining pools have announced their support for the upgrade: Poolin, Slush Pool, and BTC.com. According to BTC.com, the three pools collectively manage around 25% of the Bitcoin network's total hash rate.

The pools currently support different activation processess.

Also nice link to https://taprootactivation.com/





Wind_FURY
Legendary
*
Offline Offline

Activity: 1862
Merit: 1121


www.Crypto.Games: Multiple coins, multiple games


View Profile
November 19, 2020, 11:45:11 AM
Merited by fillippone (2)
 #84

There are three mining pools which have started to signal support for Taproot/Schnorr activation. Poolin, Slush, and BTC.com.

BTC.com? Isn't that Roger Ver's pool?

Tracker, https://taprootactivation.com/
That's a small start: currently, those three pools contribute an overall of 25% of global hashing power. By the way, BTC.com is from Bitmain.
It's interesting to notice the already very different approaches of the first three pools signaling the upgrade:
  • Poolin - BIP9 (the same BIP for SegWit that went through tough times where the upgrade need to be activated before a specific time reaching a set threshold)
  • Slush Pool - BIP8 (UASF that would also activate the upgrade at a specific future date or block height no matter the threshold reached)
  • BTC.com - BIP8 + BIP9

Let's see when other pools join the party.


Another Chinese pool, F2Pool, has started to signal for activation as well. One of the largest pools with BTC.com, part of the mining cartel.

It might be a smooth process without any drama and politics, but Slush's BIP8 for insurance. Cool

████  ███████  ███
██████████
███      ███████
███      ███████████
██████████████████
████████
███   ████  ███████████
███ ███████████████
█████████
█████████████████
███  ███████
██████████████
███        ████████
███████████▀▀███▀▀███████████
██████▀▀     ███     ▀▀██████
████▀   ▄▄█████████▄▄   ▀████
████▄▄▄███▀  ▀█▀  ▀███▄▄▄████
██▀▀▀██▀      ▀      ▀██▀▀▀██
█▀  ▄██               ██▄  ▀█
█   ████▄▄         ▄▄████   █
█▄  ▀██▀             ▀██▀  ▄█
██▄▄▄██▄             ▄██▄▄▄██
████▀▀▀███▄ ▄█ █▄ ▄███▀▀▀████
████▄   ▀▀███▄█████▀▀   ▄████
███████▄     ███     ▄███████
███████████▄▄███▄▄███████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
..PLAY NOW..
███  ███████  ████
██████████
███████      ███
███████████      ███
██████████████████
████████
███████████  ████   ███
███████████████ ███
█████████
█████████████████
███████  ███
██████████████
████████        ███
Charles-Tim
Hero Member
*****
Online Online

Activity: 490
Merit: 1218


Don't be a fool, paying 2 to get 4? It's a scam.


View Profile
November 19, 2020, 08:28:49 PM
Merited by fillippone (2)
 #85

Bitcoin mining pools representing over 54% of the network’s current hashrate have signaled support for the scaling and privacy protocol upgrade Taproot, merged into Bitcoin Core last month.



https://www.coindesk.com/bitcoin-miners-taproot-schnorr-support





BUY & SELL
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
BITCOIN ETHEREUM RIPPLE
FAQ
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
AFFILIATE PROGRAM




░██████████████████░
████████████████████
█████████▀░░░███████
█████████░░▄████████
███████▀▀░░▀▀███████
███████▄▄░░▄▄███████
█████████░░█████████

█████████░░█████████

█████████▄▄█████████

████████████████████

░██████████████████░
░██████████████████░
████████████████████
████████████▀▀▀█▀███
███░▀█████▀░░░░░▀███
███▌░░░▀▀▀░░░░░░████
████▄░░░░░░░░░░░████
█████▀░░░░░░░░░█████

██████▄░░░░░▄▄██████

█████▄▄▄▄███████████

████████████████████

░██████████████████░
░██████████████████░
████████████████████
████████████████████
███████████▀▀░░▐████
███████▀▀░░░░░█████
████▀░░░▄█▀░░░▐█████
█████▄▄█▀░░░░░██████

███████▌▄▄▄▐██████

████████████████████

████████████████████

░██████████████████░
Karartma1
Legendary
*
Offline Offline

Activity: 2240
Merit: 1377


Be Revolutionary or Die Trying


View Profile WWW
November 20, 2020, 09:35:34 AM
Merited by fillippone (2)
 #86

AntPool signaling BIP8 like SlushPool, that's some news now! Smiley Perhaps, I've been too critical a few weeks ago when I was expecting some skirmish from miners regarding the upgrade. If that's the pace of miners activating Taproot we should get there in a reasonable amount of time.
Some of them eventually had to recognize which is the one and only bitcoin that rules.

.freebitcoin.       ▄▄▄█▀▀██▄▄▄
   ▄▄██████▄▄█  █▀▀█▄▄
  ███  █▀▀███████▄▄██▀
   ▀▀▀██▄▄█  ████▀▀  ▄██
▄███▄▄  ▀▀▀▀▀▀▀  ▄▄██████
██▀▀█████▄     ▄██▀█ ▀▀██
██▄▄███▀▀██   ███▀ ▄▄  ▀█
███████▄▄███ ███▄▄ ▀▀▄  █
██▀▀████████ █████  █▀▄██
 █▄▄████████ █████   ███
  ▀████  ███ ████▄▄███▀
     ▀▀████   ████▀▀
BITCOIN
DICE
EVENT
BETTING
WIN A LAMBO !

.
            ▄▄▄▄▄▄▄▄▄▄███████████▄▄▄▄▄
▄▄▄▄▄██████████████████████████████████▄▄▄▄
▀██████████████████████████████████████████████▄▄▄
▄▄████▄█████▄████████████████████████████▄█████▄████▄▄
▀████████▀▀▀████████████████████████████████▀▀▀██████████▄
  ▀▀▀████▄▄▄███████████████████████████████▄▄▄██████████
       ▀█████▀  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  ▀█████▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.PLAY NOW.
DooMAD
Legendary
*
Online Online

Activity: 2730
Merit: 1817


Leave no FUD unchallenged


View Profile WWW
November 20, 2020, 11:15:42 AM
Last edit: November 20, 2020, 05:05:24 PM by DooMAD
 #87

AntPool signaling BIP8 like SlushPool, that's some news now! Smiley Perhaps, I've been too critical a few weeks ago when I was expecting some skirmish from miners regarding the upgrade. If that's the pace of miners activating Taproot we should get there in a reasonable amount of time.
Some of them eventually had to recognize which is the one and only bitcoin that rules.

I'm working under the impression they're treating it like any other software update.  Some will opt to do it sooner, some a bit later.  I don't get the sense there are any political motivations involved in the decision.  More a question of simply when it's convenient timing to upgrade.

I could be wrong, but I think it might just be a case of people expecting drama when there may not be any.

pawanjain
Sr. Member
****
Offline Offline

Activity: 1624
Merit: 472


AKA hmrawal


View Profile
November 20, 2020, 02:09:30 PM
Merited by JayJuanGee (1)
 #88

AntPool signaling BIP8 like SlushPool, that's some news now! Smiley Perhaps, I've been too critical a few weeks ago when I was expecting some skirmish from miners regarding the upgrade. If that's the pace of miners activating Taproot we should get there in a reasonable amount of time.
Some of them eventually had to recognize which is the one and only bitcoin that rules.
Luxor says count me in. Another mining pool has joined the race and will be activating the Taproot upgrade through BIP9.
With this a total of 6 mining pools have already signalled towards activating Taproot.


Duelbits            ▄████▄▄
          ▄█████████▄
        ▄█████████████▄
     ▄██████████████████▄
   ▄████▄▄▄█████████▄▄▄███▄
 ▄████▐▀▄▄▀▌████▐▀▄▄▀▌██

 ██████▀▀▀▀███████▀▀▀▀█████

▐████████████■▄▄▄■██████████▀
▐██████████████████████████▀
██████████████████████████▀
▀███████████████████████▀
  ▀███████████████████▀
    ▀███████████████▀
.
         ▄ ▄▄▀▀▀▀▄▄
         ▄▀▀▄      █
         █   ▀▄     █
       ▄█▄     ▀▄   █
      ▄▀ ▀▄      ▀█▀
    ▄▀     ▀█▄▄▄▀▀ ▀
  ▄▀  ▄▀  ▄▀

Live Games

   ▄▄▀▀▀▀▀▀▀▄▄
 ▄▀ ▄▄▀▀▀▀▀▄▄ ▀▄
▄▀ █ ▄  █  ▄ █ ▀▄
█ █   ▀   ▀   █ █  ▄▄▄
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀ █ █   █
█▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀█  █▄█
█ ▀▀█  ▀▀█  ▀▀█ █  █▄█

Slots
.
        ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄
        █         ▄▄  █
▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄       █
█  ▄▄         █       █
█             █       █
█   ▄▀▀▄▀▀▄   █       █
█   ▀▄   ▄▀   █       █

Blackjack
|              ▄▄▀▀█▌
          ▄▄▀█▄    █
        ▄▀     ▀▄▄ █
       █    ▄▄    ▀█
    ▄▄█    █  █   ▐▌
  ▄▀ █      ▀▀    █
▄▀  ▐▌           █
█ ▄▀▀▄▄        ▄▀
▀▀  ▄  ▀▄▄   ▄▀█
  ▄▀   ▄  ▀█▀  █
   ▄▀ ▄▀   █  █
  ▄▀ █     █▄▀
   ▄▀
NEW GAME!
CRASH 
|||
[ Đ ][ Ł ]
AVAILABLE NOW
notblox1
Hero Member
*****
Offline Offline

Activity: 1008
Merit: 594


-... .. - -.-. --- .. -.


View Profile WWW
November 21, 2020, 08:12:15 PM
 #89

Are we going to see new P2TR address format with this Taproot proposal update or there is no change for this and we keep well know formats?

No wonder that Binance pool is rejecting Taproot, and they are now one of the largest mining pool.

███████████████████████████
█████████▀▄▄▄▄▄██▀▀████████
█████▀▄█▀▀▄▄▄▄▄▄▄▀▀▄▄▀█████
████ █▀▄███████████▄▀██████
███▄█ ███████▀ ██████ █ ███
██▀█ ███  ▀▀█  ▀██████ █ ██
██ █ ████▄▄      ▀▀▀██ █ ██
██ █ █████▌        ▄██ ████
███▄█ █████▄▄   ▄▄███ █▀███
████▀█▄▀█████▌  ▀██▀▄█ ████
█████▄▀▀▄▄▀▀▀▀   ▄▄█▀▄█████
████████▄██▀▀▀▀▀▀██████████
███████████████████████████
      ██▄▄█▄▄██ █▄  ▄▄
      █████████
      ▐███████████▌
     ▄█
██████████████
     ▄▄▄▄
█▀▄▄▄▄  ▄▄▄
    ▄
▀▀▀ ▄█████▀ ▄██▀
██
  ▄
███▄▄▀▀▀▀███▀▀▀▄▄███
  ▄
██████████████████
   ███▄▄          ▄▄███
  ▄
██████████████████████▄
▄█
███
██████████████████▀▀▀▀
 ▀▀▀ ▀▀▀
██████████▀▀▀▀▀
▄▄███████████████████████▄▄
SUPER ROO'S $100,000 RESCUE
        ►   JOIN THE RAFFLE NOW!                   

▄▄███████▄▄
▄█████▀█▀█████▄
████▀▀▀ ▀ ▀▀█████
███████  ██  ▐█████
███████      ▀█████
███████  ███  █████
████▄▄▄   ▄▄▄████
▀█████▄█▄█████▀
▀▀███████▀▀

▄▄▄▄▄▄▄
▀▀███████▀▀

▄▄███████▄▄
▄██████▀██████▄
███████▀ ▀███████
███████     ███████
██████▄     ▄██████
██████▄▀▄▄▄▀▄██████
██████▄   ▄██████
▀██████▄██████▀
▀▀███████▀▀

▄▄▄▄▄▄▄
▀▀███████▀▀

▄▄███████▄▄
▄█████████████▄
███████▌ ▐███████
████████  █████████
█████▀▀   ▄▄███████
███████  ██████████
█████▌      ▄████
▀█████████████▀
▀▀███████▀▀

▄▄▄▄▄▄▄
▀▀███████▀▀
.
BITCOIN
ETHEREUM
LITECOIN
..PLAY NOW..
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
November 22, 2020, 08:12:00 AM
Merited by fillippone (2), JayJuanGee (1), nutildah (1)
 #90

Are we going to see new P2TR address format with this Taproot proposal update or there is no change for this and we keep well know formats?

The malicious lie underpinning this question was already addressed here: https://np.reddit.com/r/Bitcoin/comments/jwgbu0/mining_pool_operators_independent_miners_i/gd46yy1/

Quote
No wonder that Binance pool is rejecting Taproot,
That isn't true. Coindesk ran an article saying that binance pool was the only top-5 mining pool that hasn't made a public statement of supporting it, I'll never stop being surprised at the level of dishonest narrative spinning that happens in this "industry".

Karartma1
Legendary
*
Offline Offline

Activity: 2240
Merit: 1377


Be Revolutionary or Die Trying


View Profile WWW
November 22, 2020, 09:08:26 AM
 #91

Are we going to see new P2TR address format with this Taproot proposal update or there is no change for this and we keep well know formats?

The malicious lie underpinning this question was already addressed here: https://np.reddit.com/r/Bitcoin/comments/jwgbu0/mining_pool_operators_independent_miners_i/gd46yy1/

Quote
No wonder that Binance pool is rejecting Taproot,
That isn't true. Coindesk ran an article saying that binance pool was the only top-5 mining pool that hasn't made a public statement of supporting it, I'll never stop being surprised at the level of dishonest narrative spinning that happens in this "industry".

I guess for you it has a completely different meaning and I can sympathize with your mood. Let Coindesk be Coindesk, what can we expect from a media company which completely dismissed bitcoin for almost 4 years in favour of the infamous Blockchain Technology?
Like everyone they had to put their heads down and recognize that the only thing that matter is, of course, bitcoin.
 Wink

.freebitcoin.       ▄▄▄█▀▀██▄▄▄
   ▄▄██████▄▄█  █▀▀█▄▄
  ███  █▀▀███████▄▄██▀
   ▀▀▀██▄▄█  ████▀▀  ▄██
▄███▄▄  ▀▀▀▀▀▀▀  ▄▄██████
██▀▀█████▄     ▄██▀█ ▀▀██
██▄▄███▀▀██   ███▀ ▄▄  ▀█
███████▄▄███ ███▄▄ ▀▀▄  █
██▀▀████████ █████  █▀▄██
 █▄▄████████ █████   ███
  ▀████  ███ ████▄▄███▀
     ▀▀████   ████▀▀
BITCOIN
DICE
EVENT
BETTING
WIN A LAMBO !

.
            ▄▄▄▄▄▄▄▄▄▄███████████▄▄▄▄▄
▄▄▄▄▄██████████████████████████████████▄▄▄▄
▀██████████████████████████████████████████████▄▄▄
▄▄████▄█████▄████████████████████████████▄█████▄████▄▄
▀████████▀▀▀████████████████████████████████▀▀▀██████████▄
  ▀▀▀████▄▄▄███████████████████████████████▄▄▄██████████
       ▀█████▀  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  ▀█████▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.PLAY NOW.
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1904
Merit: 2821


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
November 22, 2020, 11:03:04 AM
Merited by notblox1 (1)
 #92

Are we going to see new P2TR address format with this Taproot proposal update or there is no change for this and we keep well know formats?

P2TR? Pay to Taproot? Taproot uses Witness version 1 and it's Bech32 address have prefix bc1p

See https://en.bitcoin.it/wiki/BIP_0341

fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
November 25, 2020, 08:07:01 AM
 #93

<...>

Quote
No wonder that Binance pool is rejecting Taproot,
That isn't true. Coindesk ran an article saying that binance pool was the only top-5 mining pool that hasn't made a public statement of supporting it, I'll never stop being surprised at the level of dishonest narrative spinning that happens in this "industry".

I guess for you it has a completely different meaning and I can sympathize with your mood. Let Coindesk be Coindesk, what can we expect from a media company which completely dismissed bitcoin for almost 4 years in favour of the infamous Blockchain Technology?
Like everyone they had to put their heads down and recognize that the only thing that matter is, of course, bitcoin.
 Wink

Asking a sincere question here: which is the dishonest narrative you are referring here? How would you have described the situation?
I am not seeing any dishonest narrative here, so I am asking because if you say differently, I am surely missing something here.
Thank you.

gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3458
Merit: 5264



View Profile
November 25, 2020, 09:08:35 AM
Last edit: November 25, 2020, 09:20:37 AM by gmaxwell
Merited by fillippone (2)
 #94

Asking a sincere question here: which is the dishonest narrative you are referring here? How would you have described the situation?
I am not seeing any dishonest narrative here, so I am asking because if you say differently, I am surely missing something here.
Thank you.

uh. The way coindesk did-- binance pool haven't commented on it.  It's more surprising that any pool has: there isn't even published software enabling it yet.

It is absolutely dishonest to characterize having said nothing about it as rejecting (as several Bitcoin "news" sites that plagiarized the coindesk article but with the additional "rejecting" claim, or the poster above who was probably regurgitating them data).

If someone published the headline "The Pope rejects the assertion that fillippone is a human being with a soul deserving of life" would you consider that dishonest?  Grin
fillippone
Legendary
*
Offline Offline

Activity: 1106
Merit: 5626


Merit Rascal wannabe Merit Cycler


View Profile
November 25, 2020, 09:46:40 AM
 #95