Bitcoin Forum
November 14, 2019, 02:02:47 PM *
News: Latest Bitcoin Core release: 0.18.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: When Schnorr will be added?  (Read 357 times)
Anarchist
Sr. Member
****
Offline Offline

Activity: 533
Merit: 258


View Profile
September 19, 2018, 09:15:49 PM
 #1

I didn't follow the tech recently. What is the current situation with schnorr sig
Any proposal, planned implementation, or something?
1573740167
Hero Member
*
Offline Offline

Posts: 1573740167

View Profile Personal Message (Offline)

Ignore
1573740167
Reply with quote  #2

1573740167
Report to moderator
1573740167
Hero Member
*
Offline Offline

Posts: 1573740167

View Profile Personal Message (Offline)

Ignore
1573740167
Reply with quote  #2

1573740167
Report to moderator
1573740167
Hero Member
*
Offline Offline

Posts: 1573740167

View Profile Personal Message (Offline)

Ignore
1573740167
Reply with quote  #2

1573740167
Report to moderator
The Bitcoin Forum is turning 10 years old! Join the community in sharing and exploring the notable posts made over the years.
1573740167
Hero Member
*
Offline Offline

Posts: 1573740167

View Profile Personal Message (Offline)

Ignore
1573740167
Reply with quote  #2

1573740167
Report to moderator
DooMAD
Legendary
*
Online Online

Activity: 2156
Merit: 1354


Leave no FUD unchallenged


View Profile WWW
September 19, 2018, 11:01:59 PM
 #2

There's certainly a proposal.  You can read the BIP here and the relevant part of the roadmap here.  Even small changes take time to go through the peer-review process and this one is actually a fairly big change, so I don't believe there is a fixed date for release or anything like that.  

RGBKey
Hero Member
*****
Offline Offline

Activity: 854
Merit: 629


rgbkey.github.io/pgp.txt


View Profile WWW
September 20, 2018, 12:15:45 AM
Last edit: September 22, 2018, 01:27:10 AM by RGBKey
 #3

What DooMAD said, Schnorr is at least as big of a change as SegWit, and we all know how easy and smooth of an upgrade that was...

Read theymos and achow101's replies
theymos
Administrator
Legendary
*
Offline Offline

Activity: 3570
Merit: 6723


View Profile
September 20, 2018, 01:26:28 AM
Merited by suchmoon (4), Foxpup (3), RGBKey (2)
 #4

There's certainly a proposal.  You can read the BIP here and the relevant part of the roadmap here.  Even small changes take time to go through the peer-review process and this one is actually a fairly big change, so I don't believe there is a fixed date for release or anything like that.  

That draft BIP is only for the details of the signature algorithm itself, since there is no standardized way to do Schnorr signatures. It's the equivalent of the SEC 1&2 standards which specify how to perform the ECDSA signing currently used in Bitcoin. That BIP needs more time for review before it is finalized, and then a separate BIP will be needed for actually integrating it into Bitcoin. I'm not following its progress too closely, but I wouldn't expect it this year.

What DooMAD said, Schnorr is at least as big of a change as SegWit, and we all know how easy and smooth of an upgrade that was...

It's far simpler than SegWit, there's even less reason for controversy around it, and it won't be done using the BIP9 process which caused SegWit's unnecessary delays. I could see the Schnorr softfork completing next year.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1820
Merit: 2081

Use SegWit and enjoy lower fees.


View Profile WWW
September 20, 2018, 02:20:11 AM
 #5

Aside from what other members already mentioned, there are few planned implementation (the idea either from user/developer) on :
1. Multi-signature address (this is obvious application/implementation)
2. Lightning Network, since 2-of-2 multisigature transaction is used when open and close channel
3. CoinJoin (along with various improvement/tweak such as SharedCoins, CoinShuffle, Stonewall and ZeroLink), since AFAIK it could break linking/analysis

And as theymos said, there's no actual BIP for Schnorr since i couldn't find any at https://github.com/bitcoin/bips

What DooMAD said, Schnorr is at least as big of a change as SegWit, and we all know how easy and smooth of an upgrade that was...

I disagree since those who would make ruckus already have their own cryptocurrency and few of them have their own fight consensus. Besides, unlike SegWit, almost no one know about Schnorr Signature/Signature Aggression expect those who interested with Bitcoin's technology.

cellard
Legendary
*
Offline Offline

Activity: 1372
Merit: 1211


View Profile
September 20, 2018, 02:25:25 AM
 #6



It's far simpler than SegWit, there's even less reason for controversy around it, and it won't be done using the BIP9 process which caused SegWit's unnecessary delays. I could see the Schnorr softfork completing next year.

So in order to add schnorr signatures, we will not go through another dramafest of mining wars fighting each other with hashrate signaling different things?

If I remember correctly satoshi used in the past softforks that didn't need mining signaling (basically a UASF? but there wasn't a name for it back then). Im not sure why segwit took that route. Was it simply to allow miners to have their say with their hashrate or was it because of technical reasons that needed it to be implemented that way?
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1820
Merit: 2081

Use SegWit and enjoy lower fees.


View Profile WWW
September 20, 2018, 02:29:06 AM
 #7



It's far simpler than SegWit, there's even less reason for controversy around it, and it won't be done using the BIP9 process which caused SegWit's unnecessary delays. I could see the Schnorr softfork completing next year.

So in order to add schnorr signatures, we will not go through another dramafest of mining wars fighting each other with hashrate signaling different things?

If I remember correctly satoshi used in the past softforks that didn't need mining signaling (basically a UASF? but there wasn't a name for it back then). Im not sure why segwit took that route. Was it simply to allow miners to have their say with their hashrate or was it because of technical reasons that needed it to be implemented that way?

That's because SegWit developer use "anyone-can-spend" and remove signature part of transaction as method for backward compability where it can be used to steal Bitcoin if majority nodes/miners don't support/use client that support SegWit.
And this is one of the argument used by opposition used to stall/disrupt consensus years ago.

AFAIK Schnorr don't use similar method for backward compability.

achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1946
Merit: 2901


bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl


View Profile WWW
September 20, 2018, 02:40:10 AM
 #8

AFAIK Schnorr don't use similar method for backward compability.
Schnorr will be added via a new segwit version number. It will not require a transaction format change, there just be a witness version 1 in addition to the current witness version 0.

theymos
Administrator
Legendary
*
Offline Offline

Activity: 3570
Merit: 6723


View Profile
September 20, 2018, 03:40:38 AM
Merited by Foxpup (4), gmaxwell (1), ETFbitcoin (1), bob123 (1)
 #9

So in order to add schnorr signatures, we will not go through another dramafest of mining wars fighting each other with hashrate signaling different things?

If I remember correctly satoshi used in the past softforks that didn't need mining signaling (basically a UASF? but there wasn't a name for it back then). Im not sure why segwit took that route. Was it simply to allow miners to have their say with their hashrate or was it because of technical reasons that needed it to be implemented that way?

Yes, Satoshi always did UASF-style softforks. AFAIK future softforks, including Schnorr, are likely to use BIP 8, which is basically a UASF with an optional miner-enabled fast-track. So miners will be able to speed things up, but not block anything.

It was thought that BIP9 would be a faster and safer way of doing softforks than the Satoshi-style method, but boy did that turn out to be wrong. It was definitely not intended to be a way of letting miners "vote"; miners are not and should not be a decision-making body for Bitcoin.

That's because SegWit developer use "anyone-can-spend" and remove signature part of transaction as method for backward compability where it can be used to steal Bitcoin if majority nodes/miners don't support/use client that support SegWit.

Those were arguments that the anti-SegWit people used, but they're not true:
 - SegWit's security doesn't depend on miners, but rather on the economy. (Otherwise the UASF attempt wouldn't have made any sense...)
 - SegWit outputs are interpreted by pre-SegWit nodes as being spendable by anyone, but that doesn't really mean anything. P2SH outputs were also interpreted as more-or-less spendable by anyone by pre-P2SH nodes.
 - The signature is not removed. Between SegWit nodes, every transaction must be accompanied by its signatures or it's invalid.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1946
Merit: 2901


bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl


View Profile WWW
September 20, 2018, 03:46:46 AM
 #10

It was thought that BIP9 would be a faster and safer way of doing softforks than the Satoshi-style method, but boy did that turn out to be wrong. It was definitely not intended to be a way of letting miners "vote"; miners are not and should not be a decision-making body for Bitcoin.
TBF, BIP 9 is very similar to the method used in previous soft forks, namely that miners signal readiness via a different version number and that the rules activate when the signalling passes a certain threshold. This had worked for several soft forks in the past, so it didn't seem like that bad of an idea. BIP 9 just made this method more sane by not having to burn version numbers and to allow for simultaneous soft forks.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1820
Merit: 2081

Use SegWit and enjoy lower fees.


View Profile WWW
September 20, 2018, 04:18:08 AM
 #11

AFAIK Schnorr don't use similar method for backward compability.
Schnorr will be added via a new segwit version number. It will not require a transaction format change, there just be a witness version 1 in addition to the current witness version 0.


Just to confirm, does that mean we'll see address starting with bc1p (according to BIP page[1]) ?

1. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32

Those were arguments that the anti-SegWit people used, but they're not true:
 - SegWit's security doesn't depend on miners, but rather on the economy. (Otherwise the UASF attempt wouldn't have made any sense...)

Looks like i misunderstood, however what if all miners use non-SegWit nodes, others use SegWit nodes and there's transaction from/to Bech32 address? AFAIK this will make such transaction never confirmed/included by miners.

- The signature is not removed. Between SegWit nodes, every transaction must be accompanied by its signatures or it's invalid.

True, but what i meant is the signature is stripped/removed when SegWit nodes communicate with non-SegWit nodes.

bones261
Legendary
*
Offline Offline

Activity: 1708
Merit: 1706



View Profile
September 20, 2018, 05:39:36 PM
 #12


Those were arguments that the anti-SegWit people used, but they're not true:
 - SegWit's security doesn't depend on miners, but rather on the economy. (Otherwise the UASF attempt wouldn't have made any sense...)

Looks like i misunderstood, however what if all miners use non-SegWit nodes, others use SegWit nodes and there's transaction from/to Bech32 address? AFAIK this will make such transaction never confirmed/included by miners.


If all of the miners decided to run non-Segwit nodes, I'm sure that would hurt the market value of BTC, and hurt their bottom line. I am sure there will eventually be at least one pool that will relent and go back to verifying segwit transactions. Or someone in this space will create a new pool that does run a segwit node. Since that pool would be paying out slightly more due to the transaction fees, many miners would switch to that pool. Other pools would probably be swayed to abandon their little boycott and start mining segwit tx again.
cellard
Legendary
*
Offline Offline

Activity: 1372
Merit: 1211


View Profile
September 21, 2018, 12:50:11 AM
 #13



It's far simpler than SegWit, there's even less reason for controversy around it, and it won't be done using the BIP9 process which caused SegWit's unnecessary delays. I could see the Schnorr softfork completing next year.

So in order to add schnorr signatures, we will not go through another dramafest of mining wars fighting each other with hashrate signaling different things?

If I remember correctly satoshi used in the past softforks that didn't need mining signaling (basically a UASF? but there wasn't a name for it back then). Im not sure why segwit took that route. Was it simply to allow miners to have their say with their hashrate or was it because of technical reasons that needed it to be implemented that way?

That's because SegWit developer use "anyone-can-spend" and remove signature part of transaction as method for backward compability where it can be used to steal Bitcoin if majority nodes/miners don't support/use client that support SegWit.
And this is one of the argument used by opposition used to stall/disrupt consensus years ago.

AFAIK Schnorr don't use similar method for backward compability.

Im aware of the segwit controversies and why it caused that. My point is, there are very conservative people in bitcoin and will basically reject forever anything that isn't a legacy transaction (addresses which begin with 1 only, and nothing else, as valid bitcoin transactions).

There is people that say the incentives to do an attack on segwit aren't there, and other's say that on a long enough timeline, the incentives will align and only these holding their coins in legacy addresses will be safe (therefore, the incentive to keep your coins in legacy addresses is already formed, unless you believe this to be nonsense and you are sure it will never happen)
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1820
Merit: 2081

Use SegWit and enjoy lower fees.


View Profile WWW
September 21, 2018, 11:44:21 AM
 #14

Looks like i misunderstood, however what if all miners use non-SegWit nodes, others use SegWit nodes and there's transaction from/to Bech32 address? AFAIK this will make such transaction never confirmed/included by miners.

If all of the miners decided to run non-Segwit nodes, I'm sure that would hurt the market value of BTC, and hurt their bottom line. I am sure there will eventually be at least one pool that will relent and go back to verifying segwit transactions. Or someone in this space will create a new pool that does run a segwit node. Since that pool would be paying out slightly more due to the transaction fees, many miners would switch to that pool. Other pools would probably be swayed to abandon their little boycott and start mining segwit tx again.

Interesting theory, but there are few things that i don't understand/agree,
1. Why would price of BTC hurt? I don't see anyone would dump Bitcoin (whether it's from pro-SegWit/anti-SegWit), unless they don't care about price of BTC/losses
2. I don't see correlation between SegWit transaction and higher fee transaction since SegWit have lower transaction size (which leads to less fees), unless SegWit supporters intentionally do that to attract people who actually don't care about the boycott OR block is far from full and mempool only contains SegWit transaction.



It's far simpler than SegWit, there's even less reason for controversy around it, and it won't be done using the BIP9 process which caused SegWit's unnecessary delays. I could see the Schnorr softfork completing next year.

So in order to add schnorr signatures, we will not go through another dramafest of mining wars fighting each other with hashrate signaling different things?

If I remember correctly satoshi used in the past softforks that didn't need mining signaling (basically a UASF? but there wasn't a name for it back then). Im not sure why segwit took that route. Was it simply to allow miners to have their say with their hashrate or was it because of technical reasons that needed it to be implemented that way?

That's because SegWit developer use "anyone-can-spend" and remove signature part of transaction as method for backward compability where it can be used to steal Bitcoin if majority nodes/miners don't support/use client that support SegWit.
And this is one of the argument used by opposition used to stall/disrupt consensus years ago.

AFAIK Schnorr don't use similar method for backward compability.

Im aware of the segwit controversies and why it caused that. My point is, there are very conservative people in bitcoin and will basically reject forever anything that isn't a legacy transaction (addresses which begin with 1 only, and nothing else, as valid bitcoin transactions).

There is people that say the incentives to do an attack on segwit aren't there, and other's say that on a long enough timeline, the incentives will align and only these holding their coins in legacy addresses will be safe (therefore, the incentive to keep your coins in legacy addresses is already formed, unless you believe this to be nonsense and you are sure it will never happen)

I doubt their number is big enough to disrupt Schnorr implantation/activation

piotr_n
Legendary
*
Offline Offline

Activity: 2016
Merit: 1054


aka tonikt


View Profile WWW
September 21, 2018, 12:05:15 PM
Last edit: September 21, 2018, 12:42:35 PM by piotr_n
Merited by figmentofmyass (2)
 #15

IMHO, the idea behind the upgrade-able witness programs, that (allegedly) won't need the miners majority suport - it is not going to work.

Just consider a simple scenario:
 * 10% of miners already upgraded to support a new witness script
 * 90% is still using the old code.

The idea in such a scenario is that the 90% of miners will not be including new type of segwit transactions in the blocks they mine.
They will also not verify such a new type of segwit transactions, inside the blocks mined by the remaining 10% (they will simply always assume these transactions as valid).

Now, what is going to happen if you have one bad miner (and I heard they are all bad;)) who decided to mine a block containing a new type of segwit transaction, but with an incorrect signature?
He would be basically spending coins which he doesn't own, from a new type of segwit address that is currently being secured by only 10% of miners.
What happens then?
It's quite simple: the 10% of miners will reject the block and will be building their blocks on top of the previous one. At the same time the 90% will accept it and continue building on top of it.
And you end up with a classic hard fork. Plus the 90% branch has been given some free coins...

So I totally disagree with the statement that it won't be needing miners support, in order to introduce schnorr or any other type of consensus change.
I mean, sure you can always try again with the UASF little boys power play politics, maybe it will even work again, but IMO social science will never beat the computer science in a long run.
Only crazy people (like BCH or BTG supporters) would stick to the branch that can be 51% attacked with only a tiny fraction of the hash power currently owned by the competitor.

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
DooMAD
Legendary
*
Online Online

Activity: 2156
Merit: 1354


Leave no FUD unchallenged


View Profile WWW
September 21, 2018, 12:35:29 PM
Last edit: September 21, 2018, 12:46:55 PM by DooMAD
 #16

It's far simpler than SegWit, there's even less reason for controversy around it, and it won't be done using the BIP9 process which caused SegWit's unnecessary delays. I could see the Schnorr softfork completing next year.

Is the plan to implement Schnorr itself as one upgrade and leave the key aggregation part for a separate, later upgrade?  I'm still not clear on that bit.

Also, will SIGHASH_NOINPUT and whichever other opcodes are needed for eltoo be included at the same time, or is that yet another softfork?


If I remember correctly satoshi used in the past softforks that didn't need mining signaling (basically a UASF? but there wasn't a name for it back then).

Yes, Satoshi always did UASF-style softforks.

That sounds like a bit of a stretch, IMO.  Prior to SegWit, the network hadn't really experienced any controversies on that kind of scale when upgrading.  UASF was considered revelatory (by some) as it was specifically designed to be implemented as:
"flag day activation" where nodes begin enforcement at a predetermined time in the future.

My understanding is that all the forks that occurred while satoshi was still around did not have a "flag day" (and were categorically not presented as an ultimatum to the miners).  Arguably, the network has never seen a UASF-style softfork.  Although many believe the threat of one pressured miners into taking the action they did to activate SegWit.

bones261
Legendary
*
Offline Offline

Activity: 1708
Merit: 1706



View Profile
September 21, 2018, 01:17:18 PM
 #17

Looks like i misunderstood, however what if all miners use non-SegWit nodes, others use SegWit nodes and there's transaction from/to Bech32 address? AFAIK this will make such transaction never confirmed/included by miners.

If all of the miners decided to run non-Segwit nodes, I'm sure that would hurt the market value of BTC, and hurt their bottom line. I am sure there will eventually be at least one pool that will relent and go back to verifying segwit transactions. Or someone in this space will create a new pool that does run a segwit node. Since that pool would be paying out slightly more due to the transaction fees, many miners would switch to that pool. Other pools would probably be swayed to abandon their little boycott and start mining segwit tx again.

Interesting theory, but there are few things that i don't understand/agree,
1. Why would price of BTC hurt? I don't see anyone would dump Bitcoin (whether it's from pro-SegWit/anti-SegWit), unless they don't care about price of BTC/losses
I would think the fact that all of the miners are colluding to boycott segwit transactions would be considered bad news to traders.
2. I don't see correlation between SegWit transaction and higher fee transaction since SegWit have lower transaction size (which leads to less fees), unless SegWit supporters intentionally do that to attract people who actually don't care about the boycott OR block is far from full and mempool only contains SegWit transaction.


A pool verifying segwit transactions in their blocks would include both non-segwit and segwit transactions. The block would have more transaction and the total fee would be a little better than a pool that verifies non-segwit transactions only.

If A is the total fee of all of the non-segwit transactions and B is the total fee of the segwit transactions, then A+B>A.


RGBKey
Hero Member
*****
Offline Offline

Activity: 854
Merit: 629


rgbkey.github.io/pgp.txt


View Profile WWW
September 22, 2018, 01:26:44 AM
 #18

Thanks theymos and achow for clearing things up. I wasn't aware that it could be added through a change in the witness version.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!