Pages:
Author

Topic: Segregated witness - The solution to Scalability (short term)? - page 8. (Read 23195 times)

legendary
Activity: 3080
Merit: 1688
lose: unfind ... loose: untight
Fraud proof is simply some compact data telling you that Bitcoin rules were violated. For many of the rules we can create compact proofs that they were violated.

Nope. Still not getting it. A block with all associated signatures already contains everything needed to determine whether or not it is fraudulent.
legendary
Activity: 1988
Merit: 1012
Beyond Imagination
I had a feeling that this solution seems quite sudden and not very well prepared, might because they are afraid of a transaction volume surge during the next rally, but in that case I'd prefer Jeff's approach to simply raise the block size limit, it does not change the code too much and can buy people more time to work on more long term solution

In fact I think even we do nothing, bitcoin still works. People will adjust themselves to their beloved bitcoin and create solutions outside of blockchain to solve the scaling problem. It is a habit that devs always want to do something to prove that they are working, but even as large as FED, considered to be the top wisdom on the planet, what they do is just print a bit more money or print a bit less money, change interest rate by step of 0.25%, nothing more than that, and they did that for decades. When you are commanding a monetary system, every step of change should be extremely cautious and small

I remember one of the core dev said a few month ago that we should wait until the block become full and see how the situation develop and then start to apply measures accordingly, I still think this is a good approach. People won't die because the banks are closed during week end, similarly, if the block become too congested, they will just reduce the transaction frequency and plan their transaction accordingly, that gives us at least 3-4 times of block space to maneuver, at least one years time to react

legendary
Activity: 4424
Merit: 4794
i think every bitcoin software whether its SPV, SW, LN or core all check every transaction before saving to file or relaying.

SPV doesn't check signatures.

relying on someone else to do checks, to trust them when they say everything is ok, and only double check when they say is wrong seems a little backwards

That's actually how a good share of the ecosystem presently operates. What did you think everyone runs a full node?

It seems to me there are fundamentals holes in your understanding that prevent you from making any progress in your comprehension of SW.

as i said, i insinuated SPV SHOULD... not does

but anyways,
ive got a full node. and i also have my own lite wallet. and guess what even though my lite wallet doesnt store the blockchain. i still know basic code get it to connect to other nodes and grab that specific blockchain data as and when needed.. id never ever ever blindly trust a unconfirmed tx based purely on how it was presented to me.. i always check txdata against other nodes history.. never would i ever just accept it and pass it on because it said op_check="im legit".

as i said im all for blockheight and txindex to be included in new transactions as it would make things far far easier to check.. but never should anyone just receive a tx and accept it on face value.

and now im more shocked that, with knowing how simple it is to make a lite wallet. why these other spv wallets are being so lazy.. its not rocket science.

businesses should not be running crappy lite versions..
if a business trains their cashiers on how to check if a bank note is counterfeit then the same should be true to bitcoin businesses using any wallet
they should all atleast be running some sort of lite client that checks history.. and that can be done without even needing to store said 7 years data.
hero member
Activity: 644
Merit: 504
Bitcoin replaces central, not commercial, banks
i think every bitcoin software whether its SPV, SW, LN or core all check every transaction before saving to file or relaying.

SPV doesn't check signatures.

relying on someone else to do checks, to trust them when they say everything is ok, and only double check when they say is wrong seems a little backwards

That's actually how a good share of the ecosystem presently operates. What did you think everyone runs a full node?

It seems to me there are fundamentals holes in your understanding that prevent you from making any progress in your comprehension of SW.

legendary
Activity: 4424
Merit: 4794

Ok, ask a question and I'll try my best to answer it. But as you are waiting for a detailed answer, I'll have to spent a significant amount of time replying. So please make it concrete.

i know splitting the blockchain into 2 is not needed.. SWliteclients can prune what they like how they like without messing with the real blockchain.
i understand the benefits of adding new opcodes..

but the real question is.. how is the fraud proof so special that only SW proposition can implement it. explain how the fraud proof works in your own words
"Have you stopped beating your wife?" Who argues that only SW can implement fraud proofs? It's a neat additional feature that is relatively straighforward to implement with SW.

Fraud proof is simply some compact data telling you that Bitcoin rules were violated. For many of the rules we can create compact proofs that they were violated. But there are two types of fraud that we can't compactly prove right now. These are subsidy fraud (inflated fees) and spending from a non-existent input. Pieter Wuille suggests we store additional data with SW, that isn't present with blocks currently, so by having it we can compactly prove these types of fraud. These data are input values, and a 'path' of inputs (original block height containing that input and a position within that block). Once this data is made a consensus rule, full nodes can simply broadcast, say, a message telling you "This input is invalid because it doesn't exist within the block it claims to", then you check that and decide to ignore the chain with this invalid input.

Fraud proofs are still more of a theoretical approach, and will require careful engineering to make them operational. But making all consensus rules compactly provable is a necessary step towards that.

or more simply.. if someone has already checked it.. instead of writing in an opcode to say its invalid.. they just dont relay it..
relying on someone else to do checks, to trust them when they say everything is ok, and only double check when they say is wrong seems a little backwards

even right now i can check a tx from back in 2009 and see if its valid just searching the txid....
i agree that adding in the blockheight and tx position of originating confirmed funds in a new unconfirmed tx can make searching the original tx easier.. but if its invalid.. you simply dont relay it.. bt i still dont see this a fraud proofing.. just making the checking mechanism slight faster (microseconds) by having the header and tx index.
i hopefully dont want to see anyone relaying an invalid tx just to tell someone its invalid. and they blindly trust opcodes without checking source.

i think every bitcoin software whether its SPV, SW, LN or core all check every transaction before saving to file or relaying. never should they just see
OP_Check="im legit" and accept it blindly. nor should they ever receive a invalid transaction, thats already been checked as invalid

that said im all for blockheight txindex.. just not the other part
legendary
Activity: 1386
Merit: 1009

Ok, ask a question and I'll try my best to answer it. But as you are waiting for a detailed answer, I'll have to spent a significant amount of time replying. So please make it concrete.

i know splitting the blockchain into 2 is not needed.. SWliteclients can prune what they like how they like without messing with the real blockchain.
i understand the benefits of adding new opcodes..

but the real question is.. how is the fraud proof so special that only SW proposition can implement it. explain how the fraud proof works in your own words
"Have you stopped beating your wife?" Who argues that only SW can implement fraud proofs? It's a neat additional feature that is relatively straighforward to implement with SW.

Fraud proof is simply some compact data telling you that Bitcoin rules were violated. For many of the rules we can create compact proofs that they were violated. But there are two types of fraud that we can't compactly prove right now. These are subsidy fraud (inflated fees) and spending from a non-existent input. Pieter Wuille suggests we store additional data with SW, that isn't present with blocks currently, so by having it we can compactly prove these types of fraud. These data are input values, and a 'path' of inputs (original block height containing that input and a position within that block). Once this data is made a consensus rule, full nodes can simply broadcast, say, a message telling you "This input is invalid because it doesn't exist within the block it claims to", then you check that and decide to ignore the chain with this invalid input.

Fraud proofs are still more of a theoretical approach, and will require careful engineering to make them operational. But making all consensus rules compactly provable is a necessary step towards that.
sr. member
Activity: 346
Merit: 250
typically an honest dev will barely understand or test how malicious users exploiting the weakness of the system.

I'm sorry but that's not knowing the thought process of current core devs.

Adversarial environments are all Peter Todd talks about.


That's what she said.
hero member
Activity: 644
Merit: 504
Bitcoin replaces central, not commercial, banks
typically an honest dev will barely understand or test how malicious users exploiting the weakness of the system.

I'm sorry but that's not knowing the thought process of current core devs.

Adversarial environments are all Peter Todd talks about.
legendary
Activity: 2156
Merit: 1393
You lead and I'll watch you walk away.
So, have you posted your concerns on the Bitcoin-dev discussion board yet?

once i get home. i will

Good, please keep us informed. I'd like to know if I'm on the wrong side on this. I'm not really a big fan of throwing money away. It's obvious that something major will be done in 2016 but I'd prefer to not sit out the whole year waiting for the dust to settle.
legendary
Activity: 1988
Merit: 1012
Beyond Imagination


its all theory but here is a story

mining pools will still be full node
in 2015 a tx looks like [txdata&sig]. in 2016 SW softfork would look like [txdata][sig] to a full node. so no worries about miners (i hope)

but it would only be [txdata] relayed/saved to a SWClient wallet..

what i could then do, is hack your SWClient so that im the only relay node you connect to.
i do this for 4 people just so your not curious about lack of network connects.
so i could make a [txdata] that is satoshi -> franky 50btc.
i send the [txdata] to you all. and because you all have the same [txdata].. you accept it (remember you cant contact a fullnode to check signature as you are in my hacked circle).
i then say 'bob im satoshi's friend as you can see he gave me 50btc,  i want to give you 50btc if you send me 5000LTC or $15,000.' your happy because its a cheap deal and also you think you will get fame for receiving funds originally from satoshi.. afterall the [txdata] shows that the satoshi funds came to me
you agree so i make a new [txdata] that shows franky -> bob.
you also see for other connections with the same [txdata] crediting you with 50btc
you then send me the litecoin/dollar funds..
i release you from my hacked circle, where you realise that the [txdata] is all fake.. and ive just run off with your litecoins or dollars.. all because you did not have the signatures stored to check locally while you were not able to check the real data.

Exactly, and this is just one of the security risk that is possible under the new implementation, and typically an honest dev will barely understand or test how malicious users exploiting the weakness of the system. So the real damage might only happen when the software is in live traffic



legendary
Activity: 4424
Merit: 4794

Ok, ask a question and I'll try my best to answer it. But as you are waiting for a detailed answer, I'll have to spent a significant amount of time replying. So please make it concrete.

i know splitting the blockchain into 2 is not needed.. SWliteclients can prune what they like how they like without messing with the real blockchain.
i understand the benefits of adding new opcodes..

but the real question is.. how is the fraud proof so special that only SW proposition can implement it. explain how the fraud proof works in your own words
legendary
Activity: 4424
Merit: 4794
So, have you posted your concerns on the Bitcoin-dev discussion board yet?

once i get home. i will
legendary
Activity: 1386
Merit: 1009
If full nodes are still needed then they are still the slowest bottleneck of the system, the SW implementation won't improve the bottleneck then what's the benefit?

Anyway this is just a generalized talk, I am not aiming SW, just showing by changing the protocol you can do whatever thing to bitcoin. So a change to protocol should be very carefully tested and reviewed, but due to the complexity of the codes, the review will be quite difficult
What constitutes a full node might change over time, as more advanced features, like UTXO commitments, are implemented. But yes, they are still the bottleneck, and the SW doesn't claim fixing it. The benefits are those listed in the OP, on the picture.

lol.. i love it how a few people are so commited to pointing out the picture but without explanation..
so here is my picture
[ img]http://www.amitbhawani.com/blog/wp-content/uploads/2010/04/Olive-Zipbook-3G.jpg[ /img]

now tell me..
will it play Call of duty on full res.
will does it have HMDI
is the screen technicolor or just black and white
is the pre-installed windows set to english or japanese.
does it come with a power cable?

yea pictures with list of features can say one thing.. but they dont explain the details people really need.. so can people stop saying 'look at the picture' as it explains nothing

Ok, ask a question and I'll try my best to answer it. But as you are waiting for a detailed answer, I'll have to spent a significant amount of time replying. So please make it concrete.
legendary
Activity: 2156
Merit: 1393
You lead and I'll watch you walk away.
If full nodes are still needed then they are still the slowest bottleneck of the system, the SW implementation won't improve the bottleneck then what's the benefit?

Anyway this is just a generalized talk, I am not aiming SW, just showing by changing the protocol you can do whatever thing to bitcoin. So a change to protocol should be very carefully tested and reviewed, but due to the complexity of the codes, the review will be quite difficult
What constitutes a full node might change over time, as more advanced features, like UTXO commitments, are implemented. But yes, they are still the bottleneck, and the SW doesn't claim fixing it. The benefits are those listed in the OP, on the picture.

lol.. i love it how a few people are so commited to pointing out the picture but without explanation..
so here is my picture


now tell me..
will it play Call of duty on full res.
will does it have HMDI
is the screen technicolor or just black and white
is the pre-installed windows set to english or japanese.
does it come with a power cable?

yea pictures with list of features can say one thing.. but they dont explain the details people really need.. so can people stop saying 'look at the picture' as it explains nothing


So, have you posted your concerns on the Bitcoin-dev discussion board yet?
legendary
Activity: 4424
Merit: 4794
If full nodes are still needed then they are still the slowest bottleneck of the system, the SW implementation won't improve the bottleneck then what's the benefit?

Anyway this is just a generalized talk, I am not aiming SW, just showing by changing the protocol you can do whatever thing to bitcoin. So a change to protocol should be very carefully tested and reviewed, but due to the complexity of the codes, the review will be quite difficult
What constitutes a full node might change over time, as more advanced features, like UTXO commitments, are implemented. But yes, they are still the bottleneck, and the SW doesn't claim fixing it. The benefits are those listed in the OP, on the picture.

lol.. i love it how a few people are so commited to pointing out the picture but without explanation..
so here is my picture


now tell me..
will it play Call of duty on full res.
will does it have HMDI
is the screen technicolor or just black and white
is the pre-installed windows set to english or japanese.
does it come with a power cable?

yea pictures with list of features can say one thing.. but they dont explain the details people really need.. so can people stop saying 'look at the picture' as it explains nothing
legendary
Activity: 1386
Merit: 1009
If full nodes are still needed then they are still the slowest bottleneck of the system, the SW implementation won't improve the bottleneck then what's the benefit?

Anyway this is just a generalized talk, I am not aiming SW, just showing by changing the protocol you can do whatever thing to bitcoin. So a change to protocol should be very carefully tested and reviewed, but due to the complexity of the codes, the review will be quite difficult
What constitutes a full node might change over time, as more advanced features, like UTXO commitments, are implemented. But yes, they are still the bottleneck, and the SW doesn't claim fixing it. The benefits are those listed in the OP, on the picture.
legendary
Activity: 1988
Merit: 1012
Beyond Imagination
In fact, this possible change in bitcoin architecture raised a question: Are your bitcoin safe in a cold storage?

I used to believe that it is protected by the public-private key cryptography, e.g. without the signature generated from private key, the coin at certain address can not be spent

But now I realized that this really depends on the client running on the nodes

If a group of nodes are running a new version which does not need the signature to spend coins, then that version can spend anyone's coin without their signature (The new version can use a new signature scheme to protect their new address). Of course this transaction would not be known to the old client since that is not part of the old protocol, so in the old client coins are still there but in the new client the coins have already been spent. After the old client upgraded to new, the coins are gone

And there is really motivation in doing this: Since by the time when over 99% of the client is running new software, the old client essentially becomes minority thus have to upgrade to the new version because almost no node is using the old version anymore. So, by successfully rolling out a new version you can steal other's coins, especially Satoshi's 1 million coins, doesn't that sounds like a good idea?

I'm not talking about developer's ethics here, it is just a technical possibility that will attract lots of criminals, and criminals really does not care about bitcoin's long term success, they just need to cash out the stolen coins at exchanges and they are done. In a word, if nodes could not prevent the protocol from being changed to something malicious, then you essentially can not protect your bitcoin at all. And the more complex the code is, the easier to hide malicious implementations
First of all, signatures are separated only for transactions that are spending from new SW-compatible outputs. As Gavin explains it, the scriptPubKey will be like this:
Code:
PUSHDATA [version_byte + validation_script]
Old transactions will still employ the current mechanism. This 'old' mechanism will be preserved, and there's no real chance spending from old outputs will be made obsolete (there's a chance sending to 'old' addresses will be made non-standard though, but I also doubt that, given the implications).

I do not understand what an attack vector you are discribing here. Old versions will have decreased security because they will have to assume (w/r/t to those transactions they won't be able to fully check) that the longest chain is the valid one. This kind of an assumption is already here for SPV wallets, which, to my knowledge, are an overwhelming majority these days. But thanks to fraud proofs, the SW will be able to strenghten their security.

Anyway, it's always been that full nodes provide the highest security possible. The full node verifies that the coins you receive are valid. Full nodes act as a check against dishonest miners. It will stay this way.

If full nodes are still needed then they are still the slowest bottleneck of the system, the SW implementation won't improve the bottleneck then what's the benefit?

Anyway this is just a generalized talk, I am not aiming SW, just showing by changing the protocol you can do whatever thing to bitcoin. So a change to protocol should be very carefully tested and reviewed, but due to the complexity of the codes, the review will be quite difficult
legendary
Activity: 1386
Merit: 1009
Exchanges and merchants accept such a new version simply because they heard that it can bring more transaction capacity, can fix bugs, can reduce the block size and increase performance. etc... And because the code and the implementation is so complex they don't have time to check every detail
I see you concerns and I must admit that such a situation is theoretically possible, but there are two things I must note that make it less likely practically:
1) there are many experts that are evaluating proposals. It raises the bar for any controversial change.
2) SW is not as complex as you are painting it.

Anyway, the possible soft-fork is still months away, so you'll have time to evaluate it yourself.
legendary
Activity: 4424
Merit: 4794
In fact, this possible change in bitcoin architecture raised a question: Are your bitcoin safe in a cold storage?

I used to believe that it is protected by the public-private key cryptography, e.g. without the signature generated from private key, the coin at certain address can not be spent

But now I realized that this really depends on the client running on the nodes

If a group of nodes are running a new version which does not need the signature to spend coins, then that version can spend anyone's coin without their signature (The new version can use a new signature scheme to protect their new address). Of course this transaction would not be known to the old client since that is not part of the old protocol, so in the old client coins are still there but in the new client the coins have already been spent. After the old client upgraded to new, the coins are gone

And there is really motivation in doing this: Since by the time when over 99% of the client is running new software, the old client essentially becomes minority thus have to upgrade to the new version because almost no node is using the old version anymore. So, by successfully rolling out a new version you can steal other's coins, especially Satoshi's 1 million coins, doesn't that sounds like a good idea?

I'm not talking about developer's ethics here, it is just a technical possibility that will attract lots of people. In a word, if nodes could not prevent the protocol from being changed to something malicious, then you essentially can not protect your bitcoin at all. And the more complex the code is, the easier to hide malicious implementations

IMHO thats only the case if:
 - majority of miners runs new version
 - satoshi moves his coins to a new address
 - majority of miners decide to roll back to old version

or did i miss something?

its all theory but here is a story

mining pools will still be full node
in 2015 a tx looks like [txdata&sig]. in 2016 SW softfork would look like [txdata][sig] to a full node. so no worries about miners (i hope)

but it would only be [txdata] relayed/saved to a SWClient wallet..

what i could then do, is hack your SWClient so that im the only relay node you connect to.
i do this for 4 people just so your not curious about lack of network connects.
so i could make a [txdata] that is satoshi -> franky 50btc.
i send the [txdata] to you all. and because you all have the same [txdata].. you accept it (remember you cant contact a fullnode to check signature as you are in my hacked circle).
i then say 'bob im satoshi's friend as you can see he gave me 50btc,  i want to give you 50btc if you send me 5000LTC or $15,000.' your happy because its a cheap deal and also you think you will get fame for receiving funds originally from satoshi.. afterall the [txdata] shows that the satoshi funds came to me
you agree so i make a new [txdata] that shows franky -> bob.
you also see for other connections with the same [txdata] crediting you with 50btc
you then send me the litecoin/dollar funds..
i release you from my hacked circle, where you realise that the [txdata] is all fake.. and ive just run off with your litecoins or dollars.. all because you did not have the signatures stored to check locally while you were not able to check the real data.
legendary
Activity: 1988
Merit: 1012
Beyond Imagination

IMHO thats only the case if:
 - majority of miners runs new version
 - satoshi moves his coins to a new address
 - majority of miners decide to roll back to old version

or did i miss something?

In this order:

1. Some large miners start to run a new version that can spend satoshi's coin without signature (in new version you can redefine what is a valid transaction)
2. These large miners moved satoshi's coin to their own address in the new version
3. These miners promote the new version to be widely accepted by exchanges and merchants
4. They sell the 1 million coins and gone

Since no one else except Satoshi will notice the difference, and in this case majority of the miners already get Satoshi's coins and be satisfied with the new version. Even Satoshi comes out and protest, it does not make any sense any more

i dont think 3 would work ;-)
why should exchanges and merchants accept such a bitcoin version?

Sorry, I have changed the order a little bit to make it more realistic, they should first push for mass adoption and then do the malicious transaction

Exchanges and merchants accept such a new version simply because they heard that it can bring more transaction capacity, can fix bugs, can reduce the block size and increase performance. etc... And because the code and the implementation is so complex they don't have time to check every detail
Pages:
Jump to: