Topic: Roger Ver massacred by Johnny (from Blockstream) (Read 2514 times)
Johnny was amazing in this but Trace Mayer also managed to land a devastating blow in the single comment he made to Roger. Roger was essentially proposing a trust based system which prompted Trace to ask 'in that case why have a blockchain at all'.
id like to see a technical writeup of your claims because they undermine the whole experiment and im skeptical unless you have some math or code to show
what if i told you CLTV if you read what it does is AFTER the close channel transaction confirms. funds are unavailable to spend and in a maturity bubble like blockreward 100confirm (real world feel of the 3-5day bank delay spending of funds)
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#freezing-funds
note the blue below FROZEN IN UTXO DIRECTLY ON THE BLOCKCHAIN = confirmed TX froze out from being spent(meaning its not about holding unconfirmed in mempool for X.. but getting confirmed but THEN unspendable for X
what if i told you CSV if you read what it does is AFTER the close channel transaction confirms. while maturing. the other party(cosigner) can revoke the payment to themselves(real world feel of paypal/credit card chargebacks)
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#retroactive-invalidationnote the purple "delayed" below is referring to CLTV
Quote
Retroactive Invalidation
In many instances, we would like to create contracts that can be revoked in case of some future event. However, given the immutable nature of the blockchain, it is practically impossible to retroactively invalidate a previous commitment that has already confirmed. The only mechanism we really have for retroactive invalidation is blockchain reorganization which, for fundamental security reasons, is designed to be very hard and very expensive to do.
Despite this limitation, we do have a way to provide something functionally similar to retroactive invalidation while preserving irreversibility of past commitments using CHECKSEQUENCEVERIFY. By constructing scripts with multiple branches of execution where one or more of the branches are delayed we provide a time window in which someone can supply an invalidation condition that allows the output to be spent, effectively invalidating the would-be delayed branch and potentially discouraging another party from broadcasting the transaction in the first place. If the invalidation condition does not occur before the timeout, the delayed branch becomes spendable, honoring the original contract.
In many instances, we would like to create contracts that can be revoked in case of some future event. However, given the immutable nature of the blockchain, it is practically impossible to retroactively invalidate a previous commitment that has already confirmed. The only mechanism we really have for retroactive invalidation is blockchain reorganization which, for fundamental security reasons, is designed to be very hard and very expensive to do.
Despite this limitation, we do have a way to provide something functionally similar to retroactive invalidation while preserving irreversibility of past commitments using CHECKSEQUENCEVERIFY. By constructing scripts with multiple branches of execution where one or more of the branches are delayed we provide a time window in which someone can supply an invalidation condition that allows the output to be spent, effectively invalidating the would-be delayed branch and potentially discouraging another party from broadcasting the transaction in the first place. If the invalidation condition does not occur before the timeout, the delayed branch becomes spendable, honoring the original contract.
I thought they both did a good job and were able to articulate their positions well. I think the way forward lands somewhere in the middle and the solution needs to consider miners, users, and developers.
There were 2 things that shocked me about the chat... Roger saying that not spending BTC gives it it's value, and Johnny saying that he only uses Bitcoin once a month.
There were 2 things that shocked me about the chat... Roger saying that not spending BTC gives it it's value, and Johnny saying that he only uses Bitcoin once a month.
Don't we all.
The truth of it is not all of us are dark market users so there is really no need to spend Bitcoin. If ever we want to buy something online, credit cards are easier and gives us more choices of products to buy. So what happens is a big percentage of "Bitcoiners" only hold their coins waiting for it to "go to the moon".
Not sure what pitches those are. I honestly have no idea why people worship blockstream, other than that people like Greg and Adam used to
do good things for Bitcoin in the past.
I'm not too worried about downstream nodes.
My big beef with Blockstream's approach is simply forcing people off the main chain, and pushing for
layers, which opens up pandora's box. For example, let's say they came out with LN 1.0 which was
somehow proven to be ideal: permissionless, anonymous, shenanigan-free, etc. What stops them from forcing
(or deceiving) the network to upgrade to LN 2.0 which is not, especially since they remain entrenched
as the controllers of the code?
do good things for Bitcoin in the past.
I'm not too worried about downstream nodes.
My big beef with Blockstream's approach is simply forcing people off the main chain, and pushing for
layers, which opens up pandora's box. For example, let's say they came out with LN 1.0 which was
somehow proven to be ideal: permissionless, anonymous, shenanigan-free, etc. What stops them from forcing
(or deceiving) the network to upgrade to LN 2.0 which is not, especially since they remain entrenched
as the controllers of the code?
what if i told you LN is buggy (remember the one-use address issues where signing a tx using the same key multiple times could reveal said privkey)
what if i told you CLTV if you read what it does is AFTER the close channel transaction confirms. funds are unavailable to spend and in a maturity bubble like blockreward 100confirm (real world feel of the 3-5day bank delay spending of funds)
what if i told you CSV if you read what it does is AFTER the close channel transaction confirms. while maturing. the other party(cosigner) can revoke the payment to themselves(real world feel of paypal/credit card chargebacks)
LN is not intended for everyone. LN is intented for people that spend micro amounts multiple times a day. (faucet raiders) and thats its niche.
LN wont see satisfaction from regular users that just want to spend once or twice a month to pay rent or take a salary
what if i told you its not permissionless.. because you cant simply send funds to a person. you need the person your in contract with to authorise (remember its a multisig)
and if using hops. you need each hop to AGREE(permission) to use them as a hop.
and if its a hub you need the hub to agree(permission)
its then no longer just peer to peer permissionless, but needing other people to sign off on YOUR funds
Not sure what pitches those are. I honestly have no idea why people worship blockstream, other than that people like Greg and Adam used to
do good things for Bitcoin in the past.
I'm not too worried about downstream nodes.
My big beef with Blockstream's approach is simply forcing people off the main chain, and pushing for
layers, which opens up pandora's box. For example, let's say they came out with LN 1.0 which was
somehow proven to be ideal: permissionless, anonymous, shenanigan-free, etc. What stops them from forcing
(or deceiving) the network to upgrade to LN 2.0 which is not, especially since they remain entrenched
as the controllers of the code?
do good things for Bitcoin in the past.
I'm not too worried about downstream nodes.
My big beef with Blockstream's approach is simply forcing people off the main chain, and pushing for
layers, which opens up pandora's box. For example, let's say they came out with LN 1.0 which was
somehow proven to be ideal: permissionless, anonymous, shenanigan-free, etc. What stops them from forcing
(or deceiving) the network to upgrade to LN 2.0 which is not, especially since they remain entrenched
as the controllers of the code?
what if i told you LN is buggy (remember the one-use address issues where signing a tx using the same key multiple times could reveal said privkey)
what if i told you CLTV if you read what it does is AFTER the close channel transaction confirms. funds are unavailable to spend and in a maturity bubble like blockreward 100confirm (real world feel of the 3-5day bank delay spending of funds)
what if i told you CSV if you read what it does is AFTER the close channel transaction confirms. while maturing. the other party(cosigner) can revoke the payment to themselves(real world feel of paypal/credit card chargebacks)
LN is not intended for everyone. LN is intented for people that spend micro amounts multiple times a day. (faucet raiders) and thats its niche.
LN wont see satisfaction from regular users that just want to spend once or twice a month to pay rent or take a salary
what if i told you its not permissionless.. because you cant simply send funds to a person. you need the person your in contract with to authorise (remember its a multisig)
and if using hops. you need each hop to AGREE(permission) to use them as a hop.
and if its a hub you need the hub to agree(permission)
its then no longer just peer to peer permissionless, but needing other people to sign off on YOUR funds
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
Well, all that is basically saying is after segwit would be activated, nodes need to play ball with segwit...
but what i'm asking is how is blockstream itself being a filter (as opposed to segwit nodes)
but what i'm asking is how is blockstream itself being a filter (as opposed to segwit nodes)
FIBRE
sounds like its just a relay network that is optional. Doesn't appear to be part of the data chain you are talking about.
please forget the 20 second elevator sales pitches that have lead many to kiss blockstream ass, and go look at the fine details.
think about the net work topology. how blockstreams creations are at the UPSTREAM (closest to pools) and how the data filters down to the hodge podge of nodes that are down stream that are not
full archival 100% validation 100% relay nodes.
Not sure what pitches those are. I honestly have no idea why people worship blockstream, other than that people like Greg and Adam used to
do good things for Bitcoin in the past.
I'm not too worried about downstream nodes.
My big beef with Blockstream's approach is simply forcing people off the main chain, and pushing for
layers, which opens up pandora's box. For example, let's say they came out with LN 1.0 which was
somehow proven to be ideal: permissionless, anonymous, shenanigan-free, etc. What stops them from forcing
(or deceiving) the network to upgrade to LN 2.0 which is not, especially since they remain entrenched
as the controllers of the code?
Well, all that is basically saying is after segwit would be activated, nodes need to play ball with segwit...
but what i'm asking is how is blockstream itself being a filter (as opposed to segwit nodes)
but what i'm asking is how is blockstream itself being a filter (as opposed to segwit nodes)
FIBRE
sounds like its just a relay network that is optional. Doesn't appear to be part of the data chain you are talking about.
please forget the 20 second elevator sales pitches that have lead many to kiss blockstream ass, and go look at the fine details.
think about the net work topology. how blockstreams creations are at the UPSTREAM (closest to pools) and how the data filters down to the hodge podge of nodes that are down stream that are not
full archival 100% validation 100% relay nodes.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
Well, all that is basically saying is after segwit would be activated, nodes need to play ball with segwit...
but what i'm asking is how is blockstream itself being a filter (as opposed to segwit nodes)
but what i'm asking is how is blockstream itself being a filter (as opposed to segwit nodes)
FIBRE
sounds like its just a relay network that is optional. Doesn't appear to be part of the data chain you are talking about.
We do not need bigger blocks, we need segwit/LN.
With this we go back to the beginning: How are we going to scale Bitcoin (further)?
Blocklimits are useless, segwit is useful. Get rid of blocksize limit and implement segwit. Easy
So... Let's just say "screw it" and have no limit? That's not feasible... At least not immediately feasible.
We don't need bigger blocks nor Segregated Witness, bitcoin is great as it is, price is at an all time high and people continue to use it.
There's already a 'bitcoin network' with bigger blocks and soon may have Segregated Witness active, it's called litecoin, if there was really a need for bigger blocks or more transactions we would see a rise in litecoin use, that's not happening.
There's already a 'bitcoin network' with bigger blocks and soon may have Segregated Witness active, it's called litecoin, if there was really a need for bigger blocks or more transactions we would see a rise in litecoin use, that's not happening.
Bitcoin is not great as it is. If it was then 90% of this forum would be mad people discussing ways to correct something that's working perfectly well.
People use Bitcoin because, well... What other options are there really? Litecoin isn't as widely used for payments/transacting, not even in a remote way...
Take a piece of software (serving something to end users) running on a server utilizing 80% of the system's resources constantly. In order to scale that you'd either have to increase system resources or you'd need to optimize the software.
Correct. That's exactly why we need both things to happen: more "hardware" and better "software".
Well, all that is basically saying is after segwit would be activated, nodes need to play ball with segwit...
but what i'm asking is how is blockstream itself being a filter (as opposed to segwit nodes)
but what i'm asking is how is blockstream itself being a filter (as opposed to segwit nodes)
FIBRE
Fibre coded by Matt corallo and released with bitcoin(segwit) core.
matt was an employee of blockstream at the time f helping them make FIBRE (secretly still is but as a 'technical advisor')
segwit coded mainly by sipa and released with bitcoin core.
sipa is an employee of blockstream
LN coded by rusty russell and released under blockstreams github https://github.com/ElementsProject/lightning
rusty russell is an employee of blockstream
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
Well, all that is basically saying is after segwit would be activated, nodes need to play ball with segwit...
but what i'm asking is how is blockstream itself being a filter (as opposed to segwit nodes)
but what i'm asking is how is blockstream itself being a filter (as opposed to segwit nodes)
this segwit soft gesture is not a stepping stone. its just an empty promise to hide the ability blockstream want to be upstream centralised filters for the network.
for an old node to get blockdata aftr activation it needs to connct to a segwit node because the segwit node needs to filter it to the native node.
gmaxwell calls it a upstream filter.
thats where FIBRE was invented to ring fense the pools with segwit nodes.
here it is explained in segwits own user guide
https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/
Quote
The easiest way to prevent this problem is to upgrade to Bitcoin Core 0.13.1 or another full node release that is compatible with the segwit soft fork. If you still don’t wish to upgrade, it is possible to use a newer Bitcoin Core release as a filter for older Bitcoin Core releases.
In this configuration, you set your current Bitcoin Core node (which we’ll call the “older node”) to connect exclusively to a node running Bitcoin Core 0.13.1 or later (which we’ll call the “newer node”). The newer node is connected to the Bitcoin P2P network as usual. Because the newer node knows about the segwit changes to the consensus rules, it won’t relay invalid blocks or transactions to the older node—but it will relay everything else.
In this configuration, you set your current Bitcoin Core node (which we’ll call the “older node”) to connect exclusively to a node running Bitcoin Core 0.13.1 or later (which we’ll call the “newer node”). The newer node is connected to the Bitcoin P2P network as usual. Because the newer node knows about the segwit changes to the consensus rules, it won’t relay invalid blocks or transactions to the older node—but it will relay everything else.
the even have an image
link of image to show its not a reddit propaganda creation https://bitcoincore.org/assets/images/filtering-by-upgraded-node.svg
also old nodes cannot sync TO new nodes.
pruned nodes cannot sync to ANY nodes
no witness new nodes cannot sync to full archival new nodes
making the downstream nodes a mess/hodgpodge of nodes that are not fully part of the network and relient on the upstream nodes filtering them down the data
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
this segwit soft gesture is not a stepping stone. its just an empty promise to hide the ability blockstream want to be upstream centralised filters for the network.
I fully believe this, but could you please explain in more detail about this?
It is an optin mechanism that with incentives lays out the foundation for further scaling
LN can work without segwit. segwit it doesnt lay out foundations for scaling.
(segwit is just 'sold' as a needed thing as a way to tempt people to push it, they are scrapping the bottom of the barrel for any small excuse they can to oversell its limitations and its half promises.. but people have run scenarios and seen it never meets expectations)
secondly you cannot segwit a segwit
thirdly it does not stop native key functionality. so it doesnt fix problems. infact it introduces new problems.
please spend abit of time reading beyond the 'elevator speach' of segwit. and read the code or read the full documentation. and dont let ur eyes glaze over the issues. be concerned about the issues. in short. read the small print
segwits initial promise was to fix issues...... result it cant. it just disarms the voluntary (ur words 'opt-in') key users. not the entire network
they then said 'wait its a tx count boost' but thats only if significan use of the keys. not an instant boost at activation.. result not gonna reach expectation
next they saying look it can add schnorr. and other things.. but..
but schnorr and other things requires future soft fork events anyway.. so just wait for schnorr code to be ready and do the soft fork then.. or dare i say it hard consensus then..
this segwit soft gesture is not a stepping stone. its just an empty promise to hide the ability blockstream want to be upstream centralised filters for the network.
all other things like schnorr, and other things can be implemented without segwit in many different ways. soft or hard. (pool or node&pool)
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
If it can work without segwit they would have added it or someonr would have done it on an altcoin already but segwit was required. The whitepaper is lying then you saying and you know better than the rest of the world
LN is complicated to code... that is why it hasnt been done yet. They are working on it.
It is completely false to say "they would have added it" -- heck 8mb or even 2mb would have helped things and THEY didn't do it -- not because it was difficult but because it didn't serve their agenda.. i mean 'roadmap'.
It is an optin mechanism that with incentives lays out the foundation for further scaling
LN can work without segwit. segwit it doesnt lay out foundations for scaling.
(segwit is just 'sold' as a needed thing as a way to tempt people to push it, they are scrapping the bottom of the barrel for any small excuse they can to oversell its limitations and its half promises.. but people have run scenarios and seen it never meets expectations)
secondly you cannot segwit a segwit
thirdly it does not stop native key functionality. so it doesnt fix problems. infact it introduces new problems.
please spend abit of time reading beyond the 'elevator speach' of segwit. and read the code or read the full documentation. and dont let ur eyes glaze over the issues. be concerned about the issues. in short. read the small print
It is an optin mechanism that with incentives lays out the foundation for further scaling
LN can work without segwit. segwit it doesnt lay out foundations for scaling.
(segwit is just 'sold' as a needed thing as a way to tempt people to push it, they are scrapping the bottom of the barrel for any small excuse they can to undersell its limitations and oversell its half promises. while pretending it also does things it cant do. but people have run scenarios and seen it never meets expectations)
secondly you cannot segwit a segwit
thirdly it does not stop native key functionality. so it doesnt fix problems. infact it introduces new problems.
please spend abit of time reading beyond the 'elevator speach' of segwit. and read the code or read the full documentation. and dont let ur eyes glaze over the issues. be concerned about the issues. in short. read the small print
The current proposal for Schnorr Signatures relies on script versioning, a feature which would be introduced by SegWit
and could be introduced as part of a proper hard consensus
1. segwit DOES NOT FIX THE ISSUES
it only disarms people who voluntarily use segwit keys... its like having a gun problem and then only taking the guns away from those who voluntarily walk into a police station and hand their guns in..
2. a hard consensus was on the cards. mentioned in 2015 that by summer 2017 the hard consensus will be rolling.. but blockstream paid coders backtracked their commitment early 2016 breaking the roundtable commitment. plus segwit doesnt solve the issues it promises. segwit is an empty gesture. not a 100% promise
3. 2016 has been a waste of a year for a feature that wont meet expectations.
The current proposal for Schnorr Signatures relies on script versioning, a feature which would be introduced by SegWit
and could be introduced as part of a proper hard consensus
1. segwit DOES NOT FIX THE ISSUES
it only disarms people who voluntarily use segwit keys... its like having a gun problem and then only taking the guns away from those who voluntarily walk into a police station and hand their guns in..
2. a hard consensus was on the cards. mentioned in 2015 that by summer 2017 the hard consensus will be rolling.. but blockstream paid coders backtracked their commitment early 2016 breaking the roundtable commitment. plus segwit doesnt solve the issues it promises. segwit is an empty gesture. not a 100% promise
3. 2016 has been a waste of a year for a feature that wont meet expectations.
Jump to: