ToominCoin aka "Bitcoin_Classic" #R3KT

[franky1]

the only problem is that the inexperienced bankers want to destroy bitcoin so that people invest in their fiat.

the only problem is the blockstream people want to cripple bitcoin growth so that people will invest in their 'liquid'

If Bitcoin can be destroyed by "inexperienced bankers" it doesn't deserve to live.  If Bitcoin can be crippled by "blockstream people" it doesn't deserve to live.

Notice: When the experiment ceases to be viable (ie provide useful information), it will be terminated and replaced with a new version utilizing appropriately modulated control variables.

^That's what Guy Corem and his brothers-in-arms are saying.

thats what blockstream corem say too, why do you think they want to inhibit bitcoin growth and concentrate on liquid, elements, lightning,.. to move people away from bitcoin private key fund storage

We'd love for SHA-256 to keep working for our Honey Badger, but if SHA-256 turns out to be fatally allergic to bee stings or cobras then it's time for an upgrade.

Consequently, this is Bitcoin Civil War 2 melodrama is much ado about nothing.

The SHA-256 miners will keep their jobs as the diligent, hard-working, and supremely well-paid security guards of the socioeconomic majority's Most Serene Republic.

But they will cease further forays into Palace Intrigue, because they are merely the current SHA-256 PoW means to the end of distributed antifragile Nakamoto Consensus.

There's nothing very special about the SHA-256 PoW.  Not anymore than there was about 1MB at the time it was selected as the max block size.

Bitcoin is not married to the SHA-256 PoW.  If there is a 51% mining attack by Toominista hard forkers, the Holy Blockchain is already at risk of catastrophic consensus failure, so the small block militia has little to lose and everything to gain by swapping out the centralized, compromised, and failing SHA-256 PoW for a different one.  

It's no different than replacing car's broken engine.  In the framework of the Bitcoinmobile, a new (and improved) PoW engine will still do its job, which is turning energy into Power.

It doesn't really matter if it's Scrypt, Cryptonote, constellations of prime numbers, Keccak (luke-jr) or the thing GPU-only Guy is proposing (I'm calling it CoreCycle).  All it has to be is at least as good as SHA-256, but not SHA-256.

If the SHA-256 miners try to be the boss of the Bitcoin owners, they will be fired.  Because they are so exquisitely specialized and thus completely vulnerable to PoW shift, they will quickly back down.  As mining profits have been driven down to marginal rates, SHA-256 miners cannot afford to risk missing a single 1MB block because they are fooling around with "not much testing needed" 2MB ones.

Who would understand that better than Guy Corem, CEO of Spondoolies?  _{(No points if you said 'Adam Back' or 'luke-jr!')}  

i am not convinced that there is a actual implementation that can be only GPU based forever.. eventually someone will figure out how to be more efficient, first people will pool their GPU's into gpu farms. then new chips that emulate the function more efficiently.. so it won cure asic farms.. it will just reset the hashrate race and the situation returns after just a few months.

also if GPU is suppose to be the safe heaven to protect against 51%.. then nothing stops the bankers or blockstream from buying up a crap tonne of GPU and 51% attacking using GPU..

inshort i dont think GPU mining is a viable defense, as it too can be manipulated by both sides agenda

[franky1]

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

[iCEBREAKER]

Some billionaire throws Gmax and company a few million bucks to fund open source Bitcoin development, and they want to cripple it why? Liquid is a pegged sidechain.

Liquid is a payment channel, not a pegged sidechain.  They are completely different things.  Do you not understand how Bitcoin works?

I thought Lightning was the payment channel.

Please advice on your exact degree of technical incompetence

3 years resident, 2 years intern.

Have you ever even used a compiler or written a script?

No, I'm not even a real doctor.

OK Frap.doc Junior, where's the citation for your outrageous/libelous "billionaire bribed Gmax to cripple Bitcon" claim?  No rush, we'll wait.

...

...

Anyway, Lightning is one possible implementation for the general idea of a payment channel.  It's like how there's more than one kind of band-aid, but there is the well-known official Band-Aid too (and they come in different shapes/sizes/fun designs/prices/materials).

If you don't know what write caches are and why it's a Very Good Thing for your CPU, hard drive, OS, and torrent client to each have one, you'll never understand, much less like, payment channels such as Lightning.  Sorry about that.   

As for side chains, you may be able to think of them like cities or counties within a state.  They can set their own local laws as they like, as long as they do not conflict with the nation they are part of.  Your Bitcoins have to obey the local laws while they are visiting a sidechain, but can leave if they don't like it.

Good luck in school.  I recommend doing eye care; it seems cushy.  A few minutes zapping with the Lazik, a few minutes chatting up the customers, and then you can spend the rest of the day posting about how much you love buying Frappucinos with Bitcoin discounts, and how Bitcoin will surely choke to death if tx fees at Starbucks ever went above 10 cents.

[jaybny]

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

[smoothie]

wow did he really say that?

And he obviously was referring to Bitcoin Classic?

wow

[iCEBREAKER]

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.

[jaybny]

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.

[franky1]

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

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..

[franky1]

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.

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................

[01:03] <Lauda> sipa what about a client that does not support segwit?
[01:03] <maaku> Lauda: why would you care to?
[01:03] <Lauda> Just out of curiousity.
[01:04] <sipa> they won't see the witness data
[01:04] <sipa> but they also don't care about it
[01:04] <Lauda> Someone mentioned it. So it is not possible for a client that does not support Segwit to see the witness data?
[01:04] <maaku> Lauda: it is certainly possible
[01:04] <maaku> Lauda: but it's meaningless to do.
[01:05] <sipa> of course it is "possible"... but that "possible" just means supporting segwit
[01:05] <Chiwawa_> 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] <maaku> 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?

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

[jaybny]

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

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..

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?

[HostFat]

wow did he really say that?

And he obviously was referring to Bitcoin Classic?

wow

No he didn't, they are just photoshopped, brg444 is a well known liar

[iCEBREAKER]

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..

[Cconvert2G36]

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.

[franky1]

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

[jaybny]

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.

[smoothie]

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.

[franky1]

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

[Cconvert2G36]

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.

[smoothie]

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.

[Cconvert2G36]

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.)