If you know Satoshi's protocol, you would know that ANYONECANPAY has existed since the very early days, and was always intended as a feature to upgrade script types such that old nodes didn't experience the new scripts as a hard fork, no doubt ANYONECANSPEND was used for the introduction of multisig addresses too (yet you're leaving those out of your TheftCoin idea for no reason at all). So you can keep pretending that the developers have deliberately created a vulnerable new spend type all you like, you're not fooling anyone (except apparently cellard, and your
Topic: BLS signatures (better than Schnorr) - page 2. (Read 788 times)
Anonymint
If you know Satoshi's protocol, you would know that ANYONECANPAY has existed since the very early days, and was always intended as a feature to upgrade script types such that old nodes didn't experience the new scripts as a hard fork, no doubt ANYONECANSPEND was used for the introduction of multisig addresses too (yet you're leaving those out of your TheftCoin idea for no reason at all). So you can keep pretending that the developers have deliberately created a vulnerable new spend type all you like, you're not fooling anyone (except apparently cellard, and youralter ego friend from trilemma.com).
If you know Satoshi's protocol, you would know that ANYONECANPAY has existed since the very early days, and was always intended as a feature to upgrade script types such that old nodes didn't experience the new scripts as a hard fork, no doubt ANYONECANSPEND was used for the introduction of multisig addresses too (yet you're leaving those out of your TheftCoin idea for no reason at all). So you can keep pretending that the developers have deliberately created a vulnerable new spend type all you like, you're not fooling anyone (except apparently cellard, and your
*ignoring anonymong's thread derailment and continuing with the actual topic*
Some are saying that BLS signatures would take longer to verify (and I think they've now edited the medium post to reflect this), so that would mean they're not necessarily an improvement over Schnorr in some areas. It might save space, but if it's slower, that might cause other issues. There are probably trade-offs whichever route we take.
Some are saying that BLS signatures would take longer to verify (and I think they've now edited the medium post to reflect this), so that would mean they're not necessarily an improvement over Schnorr in some areas. It might save space, but if it's slower, that might cause other issues. There are probably trade-offs whichever route we take.
You keep forgetting that SegWit is forever a donation in Bitcoin’s protocol.
So a hard fork is not needed if the protocol already permits to steal from Segwit addresses (which it doesn't). Get your argument together, you're floundering quite badly. Also, get a reputable IQ test.
The recovery of SegWit donations doesn’t require a 50+% attack. That you continue to repeat that nonsense exemplifies either your dishonesty or incompetence or both.
When the Satoshi miners start spending the anyonecanspend SegWit donations to themselves in blocks that they win, the Core protocol will fork off and not accept those blocks.
There will be two chains. So the Satoshi chain doesn’t need 50+% of the Core chain’s hashrate. The Satoshi protocol chain only needs enough hashrate to get the snowball rolling and then miners will jumping for joy to go anonymously join in the bonanza.
When the Satoshi miners start spending the anyonecanspend SegWit donations to themselves in blocks that they win, the Core protocol will fork off and not accept those blocks.
There will be two chains. So the Satoshi chain doesn’t need 50+% of the Core chain’s hashrate. The Satoshi protocol chain only needs enough hashrate to get the snowball rolling and then miners will jumping for joy to go anonymously join in the bonanza.
If your proposed fork can't even get a majority hashrate, then everyone currently using Bitcoin will experience it as just the latest minority fork. That's no different to any other Bitcoin hardfork, with the attractive property that the miners following it will be exclusively composed of thieves.
No-one will realistically trust those miners to not steal coins again in another hard fork. Hence your "Satoshi" fork will actually be ThiefCoin, that zero users or businesses will follow. Price crashes, not even worth trying to sell the ThiefCoin airdrop.
You have a genius' 165 IQ, yet this is the best scare story you can summon up? Whatever test you took, ask for your money back IMO
If I am right, the Schnorr signature protocol doesn't change address formats, correct me if I am wrong
Miners could gather in a cartel and anonymously steal funds without no consequences for their reputation. They could send these coins back to legacy addresses and wait for confirmations to secure them eventually, so they increase their Bitcoin stacks without actually killing Bitcoin, they are miners and have a tons of gear, it's in their incentive to not do so, so that's why they stop there. Of course some may argue if Bitcoin would survive a post-SegWit attack scenario, that is not clear to me, but it just takes enough people thinking "this may be the opportunity of a lifetime" to start going up again. Anyone that invests after such thing happening is probably going to be someone that knows what's going on because I predict massive amounts of FUD about Bitcoin being dead, broken, unsafe etc (which was never the case assuming the hashrate is still strong by then).
That makes very little sense at all, especially not the part where the new fork continues to have market value.
The miners need "tons of gear" because they need to change Bitcoin's rules to perform the attack. That means they can change any rules they like, not just reverting Segwit. Any 51% attack is always game over, so this attack isn't somehow something new.
Are you sure that all changes involving signatures lead to a change in the address format?
Im not sure if Schnorr neither BLS would require a new format address to benefit from the positives or not, I was asking about that
This is not a credible attack. Or at least no more credible than any other unilateral hard fork is. If a majority of hashpower imposes new rules on Bitcoin to steal Segwit addresses, why stop there?
It may not be credible for you, but it is credible for other people, hence why it was controversial. It doesn't even need to be practical in it's execution, if the theory says it's possible, it will be controversial.
Miners could gather in a cartel and anonymously steal funds without no consequences for their reputation. They could send these coins back to legacy addresses and wait for confirmations to secure them eventually, so they increase their Bitcoin stacks without actually killing Bitcoin, they are miners and have a tons of gear, it's in their incentive to not do so, so that's why they stop there. Of course some may argue if Bitcoin would survive a post-SegWit attack scenario, that is not clear to me, but it just takes enough people thinking "this may be the opportunity of a lifetime" to start going up again. Anyone that invests after such thing happening is probably going to be someone that knows what's going on because I predict massive amounts of FUD about Bitcoin being dead, broken, unsafe etc (which was never the case assuming the hashrate is still strong by then).
Quote
There are a few issues though:
Multisig scheme requires two communication rounds. This can be very annoying with cold storage.
With signature aggregation we have to rely on random number generator — we can’t choose random point R deterministically like we do in ECDSA
m-of-n multisig scheme is tricky — we need to make a merkle tree of public keys that can get pretty large for large m and n.
We can‘t combine all signatures in the block to a single signature.
Multisig scheme requires two communication rounds. This can be very annoying with cold storage.
With signature aggregation we have to rely on random number generator — we can’t choose random point R deterministically like we do in ECDSA
m-of-n multisig scheme is tricky — we need to make a merkle tree of public keys that can get pretty large for large m and n.
We can‘t combine all signatures in the block to a single signature.
So Schnorr sigs are a compromise in those areas. Not familiar enough with the BLS scheme to compare them though (I think MAST improves the 3rd issue on that list when using Schnorr sigs, but doesn't nullify it)
The immediate problem of a different address format is of course adoption of said address format: It is a mess at first, takes time for users and merchants to set it up.
Are you sure that all changes involving signatures lead to a change in the address format?
The controversy with SegWit is due the anyonecanspend/mining cartel vector attack. Read posts by user anunymint. Anything that adds new angles to attack Bitcoin is always going to be controversial.
This is not a credible attack. Or at least no more credible than any other unilateral hard fork is. If a majority of hashpower imposes new rules on Bitcoin to steal Segwit addresses, why stop there?
Quote from: Carlton Banks link=topic=4543637.msg40906281#msg40906281
I thought patent retrictions were the only issue with Schnorr sigs. What are these issues, and how are BLS sigs different that they are better?
Quote
ECDSA signatures are ok. They do their job and do it well, but nothing more. We can’t combine signatures or keys and every signature has to be verified independently. With multisig transactions it becomes especially annoying. We have to check all the signatures and the corresponding public keys one by one, waste a lot of space in a block and pay large fees.
Schnorr signatures are awesome — if we do it right we can combine all signatures and public keys in the transaction to a single key and a signature and nobody will find out that they correspond to multiple keys. Also block validation can be faster — we can validate all signatures at once. There are a few issues though:
Multisig scheme requires two communication rounds. This can be very annoying with cold storage.
With signature aggregation we have to rely on random number generator — we can’t choose random point R deterministically like we do in ECDSA
m-of-n multisig scheme is tricky — we need to make a merkle tree of public keys that can get pretty large for large m and n.
We can‘t combine all signatures in the block to a single signature.
Schnorr signatures are awesome — if we do it right we can combine all signatures and public keys in the transaction to a single key and a signature and nobody will find out that they correspond to multiple keys. Also block validation can be faster — we can validate all signatures at once. There are a few issues though:
Multisig scheme requires two communication rounds. This can be very annoying with cold storage.
With signature aggregation we have to rely on random number generator — we can’t choose random point R deterministically like we do in ECDSA
m-of-n multisig scheme is tricky — we need to make a merkle tree of public keys that can get pretty large for large m and n.
We can‘t combine all signatures in the block to a single signature.
See full article here:
https://medium.com/@snigirev.stepan/bls-signatures-better-than-schnorr-5a7fe30ea716
Apparently this could be deployed via soft-fork.
Quote from: Carlton Banks link=topic=4543637.msg40906281#msg40906281
Supposedly a soft fork can be done to allow Schnorr sigs. What's controversial about address formats? Or the Segwit address format? Never heard that said before.
Yes Schnorrs can be deployed via soft-fork. The immediate problem of a different address format is of course adoption of said address format: It is a mess at first, takes time for users and merchants to set it up.
The controversy with SegWit is due the anyonecanspend/mining cartel vector attack. Read posts by user anunymint. Anything that adds new angles to attack Bitcoin is always going to be controversial.
Recently I've learned about BLS (Boneh-Lynn-Shacham) signatures and it sounds all great. Fixes the problems Schnorr brought to the table.
I thought patent retrictions were the only issue with Schnorr sigs. What are these issues, and how are BLS sigs different that they are better?
My questions are: Is this to be deployed with a hard-fork or soft-fork?
If it's a soft-fork, when can we expect it to happen? Since it would be a new address format if im not mistaken, would it be controversial like SegWit was?
If it's a soft-fork, when can we expect it to happen? Since it would be a new address format if im not mistaken, would it be controversial like SegWit was?
Supposedly a soft fork can be done to allow Schnorr sigs. What's controversial about address formats? Or the Segwit address format? Never heard that said before.
Recently I've learned about BLS (Boneh-Lynn-Shacham) signatures and it sounds all great. Fixes the problems Schnorr brought to the table.
My questions are: Is this to be deployed with a hard-fork or soft-fork?
If it's a soft-fork, when can we expect it to happen? Since it would be a new address format if im not mistaken, would it be controversial like SegWit was? Also could we bypass Schnorr and just go BLS?
My questions are: Is this to be deployed with a hard-fork or soft-fork?
If it's a soft-fork, when can we expect it to happen? Since it would be a new address format if im not mistaken, would it be controversial like SegWit was? Also could we bypass Schnorr and just go BLS?
Jump to: