https://medium.com/@vcorem/lesson-learned-from-the-classic-coup-attempt-or-why-core-needs-to-prepare-a-gpu-only-pow-6a9afe18e4b0#.uqgl92uvm
Lulzy
Topic: ToominCoin aka "Bitcoin_Classic" #R3KT - page 109. (Read 157162 times)
Guy Corem, CEO of Spondoolies Tech: Lesson learned from the Classic coup attempt or why Core needs to prepare a GPU only PoW
https://medium.com/@vcorem/lesson-learned-from-the-classic-coup-attempt-or-why-core-needs-to-prepare-a-gpu-only-pow-6a9afe18e4b0#.uqgl92uvm
Lulzy
https://medium.com/@vcorem/lesson-learned-from-the-classic-coup-attempt-or-why-core-needs-to-prepare-a-gpu-only-pow-6a9afe18e4b0#.uqgl92uvm
Lulzy
Problem: the max block size is 1MB. so when block data reaches capacity, transactions must wait to be included in next block.
Solution: remove signatures from the "block" - this will enable more transactions to fit into 1MB
signature removal only benefits users that are not full nodes..
full nodes will request the signature data, making REAL LIFE data more than 1mb
= there wont be 6000tx-8000tx for 1mb for full nodes.. it will be 2mb
there is no data saved for full nodes.
the whole point of the maxblock rule is to keep REAL LIFE data under control.. switching what to constitute as in the block is not controlling REAL LIFE data.. its just pretending it doesnt exist for the lemmings. and then increasing it for the full nodes..
you missing the whole point of why the maxblocksize is there in the first place
if people are happy to receive more then 1mb of full checkable data.. then raise the limit
so then people who want to do standard private key transactions can have 2mb of buffer space while segwit special transactions can stay at a preferential 1mb alongside having the hard 2mb limit...and be happy in their little world with their funky new transactions
you sound confident, looks like you know your shit and make sense.
but you and I know, you dont really know what your talking about. quit while your ahead.
standard rhetoric of someone who cant correct someone..
show no technical proof to rebutt claims..
dont explain details in real world terms
dont use examples..
and instead insult them and tell them to shut up..
well have a good day
its just from your posts, it obvious that you do not have full grasp of bitcoin, the issues or proposed solutions.
Problem: the max block size is 1MB. so when block data reaches capacity, transactions must wait to be included in next block.
Solution: remove signatures from the "block" - this will enable more transactions to fit into 1MB
Question: but how does a full node verify new blocks? how does a miner very transactions to include in a block?
Answer: a separate "block" of data contains just the signatures for all transactions in the block.
Note: currently full nodes never even look at signatures from old blocks when syncing the block chain. all that is used is a merkle root in the bock header.
Question: so for all clients that do not update their software, wont all new blocks fail verification?
Answer: no. to old clients they will look like valid transactions and will be considered "ANYONECANSPEND"
Please explain the exact context he used.
I assume a similar one to the one I just used. I wasn't in the channel, and thus, I didn't take the screenshot without context.
So how would you know it was out of context if you have no proof and you weren't a witness?
Seems counterintuitive.
Because he's stated elsewhere how that will be financial suicide for miners. (He is one btw.)
Please explain the exact context he used.
I assume a similar one to the one I just used. I wasn't in the channel, and thus, I didn't take the screenshot without context.
So how would you know it was out of context if you have no proof and you weren't a witness?
Seems counterintuitive.
Please explain the exact context he used.
I assume a similar one to the one I just used. I wasn't in the channel, and thus, I didn't take the screenshot without context.
you sound confident, looks like you know your shit and make sense.
but you and I know, you dont really know what your talking about. quit while your ahead.
standard rhetoric of someone who cant correct someone..
show no technical proof to rebutt claims..
dont explain details in real world terms
dont use examples..
and instead insult them and tell them to shut up..
well have a good day
wow did he really say that?
And he obviously was referring to Bitcoin Classic?
wow
This is obviously out of context, but hey, whatever.
Anything can be changed in Bitcoin. Even without old nodes even noticing they're broken in the form of segwit.
Miners decide what to run, there is no dictator, there is no Core.
Jonathan has no more power than Maxwell or anyone else.
Of course anything can be changed if enough support for it is garnered.
But for someone to say that doesn't that give the wrong impression that it is an "option" to change the parameters of the total amount of bitcoins to something else?
What context was that said in? And I don't mean in the "anything can be changed context". Because that's like saying theft is an option or central planning (bank) is an option. Inflating the supply is theft to current bitcoin holders.
Please explain the exact context he used.
so every node that does not upgrade becomes a light client. good! if you care, then upgrade!!
miners will upgrade and will be processing 2-3-4-5 MB of block data.. ok go whats the problem?
the problem is that blockstreams debate for not allowing 2.3.4.5 of block data is the china firewall, the drama of forks.. and the other nonsense drama stuff..
when infact segwit does not solve having more transactions for1mb.. FOR TRUE FULLY VALIDATING NODES. and its just a gimmick purely for lemmings to pretend they are full nodes, while passing around data they cant validate.
which makes segwit not the solution to capacity..
i agree segwit has uses in regards to transaction malleability.. but people want capacity increases.. which can only happen with more data
you sound confident, looks like you know your shit and make sense.
but you and I know, you dont really know what your talking about. quit while your ahead.
so every node that does not upgrade becomes a light client. good! if you care, then upgrade!!
miners will upgrade and will be processing 2-3-4-5 MB of block data.. ok go whats the problem?
the problem is that blockstreams debate for not allowing 2.3.4.5 of block data is the china firewall, the drama of forks.. and the other nonsense drama stuff..
when infact segwit does not solve having more transactions for1mb.. FOR TRUE FULLY VALIDATING NODES. and its just a gimmick purely for lemmings to pretend they are full nodes, while passing around data they cant validate.
which makes segwit not the solution to capacity..
i agree segwit has uses in regards to transaction malleability.. but people want capacity increases.. which can only happen with more data
wow did he really say that?
And he obviously was referring to Bitcoin Classic?
wow
This is obviously out of context, but hey, whatever.
Anything can be changed in Bitcoin. Even without old nodes even noticing they're broken in the form of segwit.
Miners decide what to run, there is no dictator, there is no Core.
Jonathan has no more power than Maxwell or anyone else.
the problem is the limit in the number of transactions per block.. who cares what the actual size of the data is?
exactly.. but blockstreams roadmap is not to increase capacity by reducing tx data.. .
segwit screws with checkability just so that lemmings can have basic unverifiable data and pretend they are fullnodes when infact they are light nodes.. not checking signatures
and here is the rub. once the lemmings are holding blocks of no signatures pretending they are powerful.. blockstream then want to add more parameters and opcodes into the mix bloating basic tx data back up.. so to allow for lightning and sidechains, there would be things like transaction version number parameters added in.. and some other stuff.. so a 1mb uncheckable block wont hold 6000-8000tx's it will instead hold 3000-4000 again....
right back to where they started, but they will still claim to lemmings that all of this new fnctionality is still possible with 1mb, while the full checking nodes will be holding more than 1mb..
there is even a laughable BIP that wants to add 250bytes of data ontop of a segwit transaction(bip47).. called a payment code. to hide the value people send each other (similar to stealth addresses ideology)
so expect that while segwit stays at the 1mb limit. to not see larger capacity of transactions at all, or for very long..
wow did he really say that?
And he obviously was referring to Bitcoin Classic?
wow
franky1 i dont think you have a full grasp of either the problem or the proposed solution.
i have grasped it..
i even managed to correct lauda infact..
Almost all of franky's posts in regards to SegWit are at least partially wrong though, and some are completely wrong.
-snip-
I won't waste my time going through the basics again. There's a security risk, i.e. new attack vector. Whether you believe that someone is going to try abusing it or not does not change the fact of its existence.the reason I said franky's posts were interesting was because I haven't verified them he might have good points, he might not!
He's starting to look like a hopeless case though. he might have good points, he might not!so my ongoing rant has been that segwit will cut off other implementations from fully validating unless they too upgraded to be segwit supporters.
your rant that everything will be fine...
you even said that the dev's said everything would be fine.. but................
Quote
[01:03] sipa what about a client that does not support segwit?
[01:03] Lauda: why would you care to?
[01:03] Just out of curiousity.
[01:04] they won't see the witness data
[01:04] but they also don't care about it
[01:04] Someone mentioned it. So it is not possible for a client that does not support Segwit to see the witness data?
[01:04] Lauda: it is certainly possible
[01:04] Lauda: but it's meaningless to do.
[01:05] of course it is "possible"... but that "possible" just means supporting segwit
[01:05] imagine people wanted to stick with bitcoin-core 0.11 and not upgrade, will they be cut off from getting witness data, by defalt if segwit gets consensus?
[01:06] Chiwawa_: they could certainly code up their wallet to get it, but again what's the point? are they going to check the witness themselves?
[01:03]
[01:03]
[01:04]
[01:04]
[01:04]
[01:04]
[01:04]
[01:05]
[01:05]
[01:06]
so unless other implementations add more code just to be able to fully validate again. they are going to get cut off and just passing the parcel of data they dont understand.. which in itself is a risk if a non-segwit miner adds data it cant check into a block.
basically
bitcoin-core v0.1
bitcoin-core v0.11
bitcoin-core v0.12
bitcoin classic
bitcoin unlimited
bitcoin xt
bitcoin .. whatever the other dozen implementations are
will be cut off from seeing signatures if segwit gets consensus..
and that makes bitcoincore v0.13SW the dictator
have a nice day.. as you are becoming a hopeless case
so you have a nice day too
who cares.. the problem is the limit in the number of transactions per block.. who cares what the actual size of the data is? (as long as we dont hit the great fire wall of china limits)
sigwit solves the problem of block tx capacity
the problem is currently being caused by the block limit of 1MB
avg tx size * number of tx <= 1MB
number of tx <= 1MB / avg tx size
so to fix - either increase numerator or decrease denominator
done
sigwit solves the problem of block tx capacity
the problem is currently being caused by the block limit of 1MB
avg tx size * number of tx <= 1MB
number of tx <= 1MB / avg tx size
so to fix - either increase numerator or decrease denominator
done
exactly.. but blockstreams roadmap is not to increase capacity by reducing tx data.. thats the illusion..
segwit says 1mb of segwit (no signatures) is 6000-8000tx instead of 3000-4000(old style)... but in china where miners want to see the signatures to validate them before throwing them into a block (good security to do so).. the data is not 6000-8000tx for 1mb.. its more than 1mb of real checkable data..
segwit screws with checkability just so that lemmings can have basic unverifiable data and pretend they are fullnodes when infact they are light nodes.. not checking signatures
and here is the rub. once the lemmings are holding blocks of no signatures pretending they are powerful.. blockstream then want to add more parameters and opcodes into the mix bloating basic tx data back up.. so to allow for lightning and sidechains, there would be things like transaction version number parameters added in.. and some other stuff.. so a 1mb uncheckable block wont hold 6000-8000tx's it will instead hold 3000-4000 again....
right back to where they started, but they will still claim to lemmings that all of this new fnctionality is still possible with 1mb, while the full checking nodes will be holding more than 1mb..
there is even a laughable BIP that wants to add 250bytes of data ontop of a segwit transaction(bip47).. called a payment code. to hide the value people send each other (similar to stealth addresses ideology)
so expect that while segwit stays at the 1mb limit. to not see larger capacity of transactions at all, or for very long..
if segwit went for 2mb... every other implementation and different bitcoin program would need to have atleast a 3mb, possibly 4mb limit just to cover whatever segwit miners sent out as their faked 2mb data limit
you keep bringng this up, is this correct? From what I understand, with segwit, it will only be 1MB for older pre-soft-fork clients. and 2mb or more for new clients. The tx and sig will be in separate data. not sure if there will be a size limit for the sig part of 1mb or more?
with segwit released .. old pre-fork clients will no longer be full checking nodes as signatures wont be included by default.. if old clients tweaked the sourcecode to allow themselves to get the extra signature data that segwit hides, to regain the position of being full checking nodes again.. then the data wont be 1mb under a segwit1mb limit.. it would be 2m of real archival fully checkable data.. if segwit in 2017 finally implemented the 2mb limit.. actual real life (not theory) data including signatures would be 4mb.. not their faked 2mb of uncheckable data
my numbers are not law.. they are just used as examples to show that if you include the hidden data, you know the stuff that FULL checking nodes need.. its bigger then what segwit wants to admit to
they want to make users not be full checking nodes and have less data. and undersell the real data requirements that full nodes will receive
franky1 i dont think you have a full grasp of either the problem or the proposed solution.
if segwit went for 2mb... every other implementation and different bitcoin program would need to have atleast a 3mb, possibly 4mb limit just to cover whatever segwit miners sent out as their faked 2mb data limit
you keep bringng this up, is this correct? From what I understand, with segwit, it will only be 1MB for older pre-soft-fork clients. and 2mb or more for new clients. The tx and sig will be in separate data. not sure if there will be a size limit for the sig part of 1mb or more?
with segwit released .. old pre-fork clients will no longer be full checking nodes as signatures wont be included by default.. if old clients tweaked the sourcecode to allow themselves to get the extra signature data that segwit hides, to regain the position of being full checking nodes again.. then the data wont be 1mb under a segwit1mb limit.. it would be 2m of real archival fully checkable data.. if segwit in 2017 finally implemented the 2mb limit.. actual real life (not theory) data including signatures would be 4mb.. not their faked 2mb of uncheckable data
my numbers are not law.. they are just used as examples to show that if you include the hidden data, you know the stuff that FULL checking nodes need.. its bigger then what segwit wants to admit to
they want to make users not be full checking nodes and have less data. and undersell the real data requirements that full nodes will receive
Anyone who wants to keep checking signatures is welcome to upgrade.
I don't remember anything about non-segregated (merged?) witness being part of Bitcoin's social contract.
Segwit probably would have been in the original version if Satoshi had the benefit of what we know now.
Segwit pays off technical debt (ie malleability is history, fancy new crypto-magics are now possible) and also gives a nice right-sized bump to the tx per second.
Win-win.
OTOH, Classic's 2MB at the cost of unpredictable fork war chaos is lose-lose.
wow did he really say that?
And he obviously was referring to Bitcoin Classic?
wow
if segwit went for 2mb... every other implementation and different bitcoin program would need to have atleast a 3mb, possibly 4mb limit just to cover whatever segwit miners sent out as their faked 2mb data limit
you keep bringng this up, is this correct? From what I understand, with segwit, it will only be 1MB for older pre-soft-fork clients. and 2mb or more for new clients. The tx and sig will be in separate data. not sure if there will be a size limit for the sig part of 1mb or more?
with segwit released .. old pre-fork clients will no longer be full checking nodes as signatures wont be included by default.. if they tweaked the sourcecode to allow themselves to get the extra signature data that segwit hides.. then the data wont be 1mb under a segwit1mb limit.. it would be 2.. if segwit in 2017 finally implemented the 2mb limit.. actual real life (not theory) data including signatures would be 4mb.. not their faked 2mb of uncheckable data
who cares.. the problem is the limit in the number of transactions per block.. who cares what the actual size of the data is? (as long as we dont hit the great fire wall of china limits)
sigwit solves the problem of block tx capacity
the problem is currently being caused by the block limit of 1MB
avg tx size * number of tx <= 1MB
number of tx <= 1MB / avg tx size
so to fix - either increase numerator or decrease denominator
done
Jump to: