And those outputs right now do not exist, or if they do, they are intentionally created
welcome to the conversation.. like i said pages ago. a MALICIOUS pool grabs the code from testnet/github. to do exactly that.. finally i think you are piecing it all together, bravo. The code is different from actual transaction outputs. Actual transaction outputs do not exist that are the segwit output type that anyone can spend from. They can't just use that code and grab any random output to spend from like that because that isn't how it works. |
|
|
|
When these outputs are spent by the input of another transaction, the signature is not in the scriptsig. THAT IS ALL THAT THIS DOES!
seriously you said it yourself but you are not realising what you are saying read the part i quoted you.. and realise that because OLD clients wont see the signatures because of exactly what you said.. then there does not need to be a signature.. because old clients wont validate it.. they would blindly overlook it if they seen a funky transaction in a block that has no scriptsig where it suppose to be.. so a malicious miner can just not sign it. (because they dont even have that random inputs key), knowing the rest of the network would overlook it. But only the segwit output types can be spent like that. Only p2wpkh and p2wsh do not need the signatures in the scriptsig. And those outputs right now do not exist, or if they do, they are intentionally created to be able to be spent by anyone. |
|
|
|
you are as naive and stck in the box as lauda..
its time you took off the fanboy hat and thought outside of the box.
It is time you actually think about what you are saying and realize you have no idea what the fuck you are talking about. i said the malicious pool will make a segwit!!!!!!!!!!!!!
a segwit transaction
a segwit transaction
a segwit transaction
Define a segwit transaction. There are segwit outputs, p2wpkh and p2wsh. When these outputs are spent by the input of another transaction, the signature is not in the scriptsig. THAT IS ALL THAT THIS DOES! malicious pool makes a segwit transaction.. that is using op_0.. not a op_true..(they are different things)
the transaction grabbed a random input from anyone. knowing that right now today the signature was not important. because current network wont see or care about signatures.
How so? How can they grab any input from anyone if the output that they are spending requires a valid sig? Let's simulate this using specific transactions and actual technical terms. Pick a random transaction and lay out exactly how this would work with the OP codes in the inputs and outputs.
This is what you are telling me: Pick a random transaction output A. I chose the first output from https://blockchain.info/tx/eecd0da0ed0c5c6a633ff23c30591af798592f4b62d10a24e21739dde0270e7fThe output is OP_DUP OP_HASH160 66e7f6ecddc8a15903acc24339c3ff1d5406da9a OP_EQUALVERIFY OP_CHECKSIG To spend it, I need to provide a valid signature in the scriptsig. The scriptsig in the spending transaction will look like THIS DOESN"T CHANGE AT ALL!! WITH SEGWIT I CANNOT SPEND THIS INPUT WITHOUT PROVIDING THAT SCRIPTSIG. |
|
|
|
There are no plans for deactivation today, but it might change in future. Bitcoin is meant to be trustless, so Im not going to store Bitcoin long term with SegWit transaction, because I would need to trust another Soft Fork wont deactivate the use of withness part where signatures are checked. No FUD, just rational from my part as I will be using SegWit transactions only for hot wallet and low amounts, not for a cold longterm storage.
You can use the witness outputs nested in a p2sh output (the kind of address that segwit wallets will be creating). The witness output scripts act as the redeemscript of the p2sh address, and because that is hashed, no one will be able to spend your coins even if for some reason a soft fork happened which deactivates segwit. This is an irrational fear and not a particularly valid one because segwit fixes the transaction malleability problem, and deactivating it would simply reintroduce the issue, something that no one wants to happen. |
|
|
|
I understand this, these SegWit transactions are meant as anyonecanspend outputs after the de-activation, the same way as today. The only thing what protects SegWit transactions from anyonecanspend after activation is just another Soft fork which deactivates use of withness part to check signatures, users should be well aware of this and act accordingly.
What do you mean deactivation? There is no plan to deactivate segwit, why would there be? By that logic, we shouldn't have use p2sh or OP_CLTV because after activation another soft fork can be used to deactivate it and those features are gone. This is an unnecessary fear and is just spreading FUD to get people to not use segwit. No, you can not spend normal transaction after any Soft fork without valid signature, but you can spend SegWit transaction without signature afer Soft fork, so "Literally anything can be changed with any kind of fork" is invalid statement.
You can create a transaction with the segwit outputs before the fork right now and be able to spend that without a signature. you cannot do that after the fork because after the fork you will need a signature to have that transaction considered valid. |
|
|
|
Is there any reason at this point in time to keep the 60GB database from 0.93.3? I'd prefer to delete it and reclaim the HD space.
Not really. You can delete it if you want, the only point of keeping it is just in case something fails horribly, which I don't think will happen. |
|
|
|
This I meant, use SegWit transactions for low valued transactions only, because they meant to be as anyone can spend and the signature is required only in withness data by certain block versions,
They are not meant as anyonecanspend outputs after the activation because they aren't anyonecanspend outputs after segwit activates. but this signature in withness data requiremet can be changed with future soft fork and new block version again.
Literally anything can be changed with any kind of fork. This is not a valid argument. |
|
|
|
--snip--
You are horribly misunderstanding segwit just like franky is. You need to realize that segwit does not affect how p2pkh, p2sh, and p2pk outputs are spent so transactions spending those outputs are still malleable. The part about not including the signatures in the scriptsig is only for the segwit output types. |
|
|
|
you realise the whole point of segwit is that scriptsig is not part of the transaction right... you know to prevent people from tweaking it for malleability..
To maintain compatibility, p2sh, p2pkh, and p2pk outputs are not change at all. There is nothing that changes how to spend from those outputs. So if you spend from p2pkh and p2pk outputs, you are still vulnerable to transaction malleability attacks (p2sh outputs are different because with segwit there will be p2wpkh and p2wsh outputs nested inside a p2sh outputs and those aren't malleable, but the old type are). The only way to not be able to have your transaction malleated is to use the segwit outputs types as your inputs. |
|
|
|
3. all the scriptsig crap is stored OUTSIDE of the tx, in the witness area.. old clients wont see it and blindly accept it without a signature.. thats the whole point of segwit.
now when a second transaction is made later it is grabbing the OUTPUT of the first transaction (not the input) which basically says 1MaliciouspoolAddress gets the coin. and uses the OUTPUT as an input for the second transaction.. and signs for it normally. because the pool owns the key for 1MaliciouspoolAddress and the confirmed block is saying that 1MaliciouspoolAddress now owns coins thanks to the funky tx before segwit
Here is the flaw in your logic. The scriptsig stuff is only stored outside of the transaction for the NEW SEGWIT OUTPUT TYPES. Segwit specified two new output types and only those two output types can have their signatures not in scriptsig. If you are spending from an OLD OUTPUT TYPE LIKE P2PKH and P2SH then you still have to have the signatures in the scriptsig. Maybe the example here: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Example will help you understand it better. Because one input in that example is p2pk, IT MUST HAVE THE SIGNATURE IN THE SCRIPTSIG. The other input is a p2wpkh (new segwit output type) which requires that the signature is in the script witness. |
|
|
|
ok i think you are getting confused..
I think you're getting confused about how bitcoin works so pretend it is sunday the 3rd of april. the network is not using segwit.
BUT
on this same day a malicious miner makes a block paying a destination address he owns.
he makes the block that has the transaction included to pay 1MaliciouspoolAddress
he owns the key for 1MaliciouspoolAddress
BUT is using inputs of funds he does not own. but knowing he is making a segwit transaction he doesnt need to worry about signatures because the old clients will ignore it.
What about a segwit transaction would make it so that he can ignore the signatures? Why would he be able to spend from an input he does not own? The input does not dictate how the output is spent, the output does. If the output says that it needs a signature in the scriptsig (e.g. a p2pkh output), then it needs a signature in the scriptsig regardless of segwit activation. |
|
|
|
Uh. No. OP_0 is currently treated as a counter, but basically as a NOP now. After segwit is released, it is treated as script versioning. The OP_0 isn't the part that matters, but rather the fact that the stack is not zero or empty and thus is true. That is what makes it anyonecanspend because if the scriptsig is empty then the stack will always evaluate to true.
i love how you try to remain disagreeing, but when you try to explain it you are actually explaining that the op_0 is like i said NOT anyone can spend. and so its not exactly like an anyone can spend transaction at all.. like i said. and that the use of the example of anyone can spend is only as an analogy comparison and not a technical duplicate.. Fine, semantics, whatever. When I refer to an anyonecanspend output, I will be referring to a output that can be spent without knowledge of the private key for the address. so back to my point. if a malicious pool adds segwit transaction the OLD clients will look passed it. meaning that the pool could grab any input from anyone and make a transaction that has a destination of a privkey the pool owns..
NOOO! The anyonecanspend output does not affect the input. What part of that do you not understand? If I take any UTXO and put that as my input, I HAVE TO SPEND FROM IT AS THE OUTPUT DICTATES. THE INPUT SCRIPT COMBINED WITH THE OUTPUT SCRIPT HAVE TO RESULT IN A NON-ZERO NON-EMPTY STACK!! The outputs of the SPENDING transaction can be anyonecanspend but THAT DOESN"T AFFECT HOW THE INPUTS OF THE TRANSACTION ARE VALIDATED! |
|
|
|
The node itself does not change, but the context in which they are spending in does. Thus, if RIGHT NOW you were to create a transaction with a segwit output, it is an anyonecanspend output and anyone can spend from that output
So the security is to make sure this output can never be spent by old nodes, how can you be sure of that? Suppose two pools with 60% hash rate, and they are sitting on the side line watching the mined blocks, once 35% of blocks are mined as segwit support, they switch to mine segwit blocks and activate it, then there will be many segwit transactions out there, and then they switch back to original software Now network are full of anyonecanspend transactions that is free for them to grab, and they have 60% of hash power so their chain become the longest, since majority of the nodes are still old style nodes (as in soft fork you don't need nodes to upgrade), these nodes will build on their chain, and the rest of the segwit nodes will fork into a minority chain since now they reject old style blocks So it is a mess after this accident, all the people who used segwit transaction will lose their money and they don't even understand what happened Nope. It's all in the deployment. There is a lock in period (grace period) before the rules go in effect. See BIP 9: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki for how the deployment actually works because they will be using versionbits. A p2wpkh (a type of segwit output) is as follows op_true is used for anyone can spend.. and valid to be relayed and valid/accepted into blocks currently op_0 does nothing.. so would get rejected when relayed but accepted(blindly ignored) in blocks however after segwit is released op_0 can be treated similarly to op_true by upgraded nodes. but still rejected at relay and blindly ignored in blocks by older nodes. there is a difference Uh. No. OP_0 is currently treated as a counter, but basically as a NOP now. After segwit is released, it is treated as script versioning. The OP_0 isn't the part that matters, but rather the fact that the stack is not zero or empty and thus is true. That is what makes it anyonecanspend because if the scriptsig is empty then the stack will always evaluate to true. |
|
|
|
maybe time you re-read it.
remember NON-segwit clients do not change. so all your fluffing around saying things will change means that you are assuming that old clients will some how understand things differently.. please think about that..
again. let this settle in
non upgraded clients do not change. they treat the transaction the same now as they would in a month. and so if you are saying that old clients can spend segwits now then you are saying that they can spend them later too... but they dont change..
The node itself does not change, but the context in which they are spending in does. Thus, if RIGHT NOW you were to create a transaction with a segwit output, it is an anyonecanspend output and anyone can spend from that output. However, after segwit activates, if you were to create a transaction with a segwit output, it is not an anyonecanspend output and only the recipient can spend from it. To a non-segwit node, in both cases, it could create a spending transaction treating the output as anyonecanspend. Before the deployment, the spending transaction would be accepted, but after, it would be rejected. my reading is that segwit transactions ARE NOT!!!! i repeat.. ARE NOT anyonecanspends. they would fail the test of anyonecanspend. HOWEVER for ONLY analogy purposes people say segwit transactions added to a block will be blindly accepted just like anyonecanspends are blindly accepted by old clients.
To new nodes, they are not anyonecanspends. To old nodes they are. It is not an analogy because old clients will validate it according to their rules and that is as an anyonecanspend output. Okay, maybe I should stop use anyonecanspend outputs. Maybe this will help you understand it: A p2wpkh (a type of segwit output) is as follows The corresponding input scriptsig is then just For a non upgraded node, it validates this by first pushing 0 bytes to the stack, then pushing OP_0, then pushing the 20 byte hash of the witness script. The stack will look like this: Because the stack is not zero, it is true and thus validates. Anyone can produce a transaction which has a scriptsig of 00 and with a segwit output, it is considered anyonecanspend by old nodes because anyone can create that scriptsig. However, segwit nodes will recognize that he OP_0 means it is a version 0 witness program and validates it as such. now onto the separate issue you keep meandering to..
please do not confuse the issue of block confirmed transactions with the relay of unconfirmed transactions.
so one more time
A POOL (not a user) a POOL adds a segwit transaction to its block, but because segwit is not activated by other POOLS the malicious pool can grab any input and pretend it is theirs becasue it knows the network wont be checking signatures yet. so it doesnt need to sign the input... and then give the the destination as a real privkey owned by them..
Segwit only creates a new OUTPUT type that is spent in a specific way. It doesn't affect how other CURRENTLY USED OUTPUT TYPES are spent. If you have a p2pkh output, to spend it, no matter of when, you MUST spend it as it is currently done. This will not change. Segwit activation does not make p2pkh and p2sh outputs magically be spent differently. Because the pool cannot spend from a p2pkh output that isn't theirs, it can't do this. The pool cannot grab any input and spend it as their because the way to spend the currently used output types are not going to change. |
|
|
|
Oh please you mean to say that reversing those changes is not a hard fork. Of course it is a hard fork. By your same argument one can introduce a 32 MB blocksize limit after say block 1000000 and claim it is not a "hard fork" Alright, if you want to call it a hard fork, then it's a hard fork. But the difference between that and now is the context of its deployment. They are not comparable. |
|
|
|
you do realise that its not actually an anyonecanspend script. and as soon as someone without segwit tried to spend it in an anyonecanspend.. it wont get accepted by legit ethical pools...
Yes, I know. Maybe I wasn't clear, but I meant BEFORE segwit's deployment. Right now, you can create a transaction that has a segwit output. Right now that output is an anyonecanspend output. Pools would not accept an attempt to spend a segwit output as anyonecanspend AFTER segwit's deployment. blindly passing it on..
They do not blindly pass on segwit transactions because those are considered non-standard and thus rejected. not because it actually is an anyonecanspend. otherwise thats another way of breaking bitcoin.. by old clients spending segwit transactions.(which u think is possible)
See above. only a malicious miner can bend their rules and accept a malicious transaction into their block, to be treated as funky by everyone else blindly accepting it as funky. but if USERS tries to make a transaction and pushed it to a pool. unless the pool was malicious and wanted strangers to spend their previous tx, then it wouldnt get in a new block. so people cant spend the funky tx...
AFTER segwit's activation, such malicious transactions spending segwit outputs as anyonecanspend are invalid. this is why i have used the word funky instead of anyonecanspend. because the anyonecanspend was for analogical reasons not technical
Anyonecanspend is technical, not analogical. An OLD node validates segwit outputs as anyonecanspend because under the old rules they are anyonecanspend. my scenario is about the block creation by a malicious pool. not the user creating transactions (which pools would dump)
Miners won't mine an an invalid block. |
|
|
|
Wanna post that here? Besides the fact that that post is full of incorrect statements, I don't want to post in that cesspool of a forum. You seem to prefer a theymos ruled forum over an uncensored one. No surprise. No, I prefer a forum where you can have a semi-intelligent discussion about the merits of the various software proposals instead of a forum where every single person has a bias towards one specific proposal and uses personal attacks and spreads misinformation about other proposals. Also, that thread is really freaking long and I don't want to read it and attempt to debunk all of the false information in one post.
1. malicious pool makes a segwit transaction to pay themselves lots of coins. from an address they dont own to an address they do own. BUT. because its 2 weeks before anyone else has segwit, it appears to others as a funky transaction. in a block.. so they blindly accept it as a block with funky transaction.
This is simply not possible. Anyonecanspend is an output type, not an input type. It is not possible to spend from addresses (from now on I will refer to them as p2pkh and p2sh outputs) that you don't own the private keys for. If it were an anyonecanspend output (like an actual one or one in segwit format) then, as the name of the output suggests, anyone could spend from that output legitimately and create whatever outputs they want. 2. so now the receiving addresses is technically classed as having lots of funds.. but no one can spend them as they dont have the keys to do so. so the transaction is locked in the block unspendable becuse although people can try making an anyone can spend, it wont be accepted into other blocks as its not technically an anyone can spend..
I don't see how that would even be the case. A segwit output would be able to be spent by everyone before segwit's activation because it is anyonecanspend. 3. weeks later when the malicious block has over 2000 confirmations. the owner of the privkey that received the funds can then move them because segwit is now live and segwit pools will see that the transaction is spending funds with 2000 confirmations(even though the tx before that is technically invalid)
See above. |
|
|
|
i do understand it. but your diverting away from a block containing transactions where the pool is paying themselves.. to talk about a different scenario about spending later....
because after the 2 weeks of the transactions being (kind of stuck) in a block.. when segwit becomes live for everyone else. the pool can then move the funds using segwit legitimately because they are moving funds from the confirmed blocks using the privkeys they own.
only way to prevent it is to roll back the chain two weeks orphaning off 2016 blocks just to make that malicious block disapear from being confirmed..
as for your newly elaborate scenario about anyone can spend.. those transactions wont be accepted in mempool of old clients. not until segwit is live.
so as i said. a malicious pool can create a block. with a 2 week headstart (2016 blocks) to secure their transaction. and then when live. they can spend the transaction.
Sorry, but I still don't understand your scenario. Can you describe it more specifically with reference to the output type that was used in the outputs? |
|
|
|
ur assuming a pool cannot made a funky segwit without 95%.. if it was impossible.. then that blows apart your whole argument about backward compatibility accepting segwit.
so lets assume a pool got the code on day one and made a funky tx, added it to a block before any of the other pools upgraded. they would treat it as a valid block with a funky tx that they just blindly pass on.
EG lets say segwit is not publicly released for 2 weeks. but a pool grabbed the code from testnet today and made loads of transactions in their pools paying themselves. knowing they have 2 weeks of never being checked
hash power doesnt even come into the argument
Clearly you don't know how segwit works. A segwit output is understood by old nodes as an anyonecanspend outputs. Spending a segwit output has a blank script sig and this is valid because the stack is not 0. So if anyone were to create a segwit transaction now, anyone could spend from the output. Segwit does not allow people to spend from normal p2pkh or p2sh outputs in a special way, they still have to spend from them in the old way. The change of segwit is the new output types and spending from those output types requires an empty script sig and a witness. I suggest that you read the BIPs for the full technical description of segwit and you should really understand how it works. I linked them in the bottom of the blog post. What do you think about the using of segwit?
Let me explain.
Today almost nobody cares about the transaction size and the fees.
What will force the users like casino, exchanges, doublers, etc to abadon their currens software which accepts p2pkh addresses and move to segwit addresses?
The fees are lower. I'm pretty sure a lot of people care about the fees, especially if you are making many transactions. Those fees do add up. Since the size of the transaction that goes towards the block size count is less, the fees will thus be lower and that incentivises people to use segwit. |
|
|
|
|
Show Posts
