adamstgBit
Legendary
Offline
Activity: 1904
Merit: 1037
Trusted Bitcoiner
|
|
March 30, 2016, 02:29:41 AM |
|
So why aren't developers supporting classic, XT , or BU ?
because all (legitimate) devs are core devs?You are suggesting it is a popularity thing that developers are trying to pad their resume with the "principally important" implementation? This seems highly unlikely because ... 1) When Developers aren't being paid, they are principally concerned with working on items they are technically interested in or that make sense(are feasible). Bitcoin Core doesn't pay any salaries , and all other sources have no restrictions on what implication to work on , in fact the only implementation to bribe developers to work on it is Classic and perhaps Bitpay's Bitcore(not to be confused with Bitcoin core). 2) Developers aren't idiots , if they really believed in Classics roadmap than they would simply move over , miner would instantly agree as they aren't against classic per say, and than Classic would become the reference implementation with their resume padded on the right one. i cant tell if you're confirming or denying my statement
|
|
|
|
BitUsher
Legendary
Offline
Activity: 994
Merit: 1035
|
|
March 30, 2016, 02:30:25 AM |
|
You can't control what kind of data gets written to a censorship-resistant database. That would be censorship. Why can't you damn cripplecoiners get that through your heads? Who isn't being true to our values here?
You object to Fidelity getting fee discounts but not SegWit users getting discounts? You gripe about externalizing costs while you helped cause the value of my investment to lose 60% in the last 27 months. Kinda rich coming from you.
You can't have it both ways. Censorship-resistance means people are going to do stuff with their freedom that you don't like. We tolerate that because it mean we can do what they don't like. That's freedom, if you can't handle it, Bitcoin maybe isn't for you.
Classic helps mitigate the selfish mining advantage the Chinese get behind the Great Firewall. Faster block propagation means less of a mining Cartel for Fidelity et. al. with which to collude.
Ahh , you are reading into my statements and making some assumptions that I am not suggesting. I never said we should censor tx or data on the blockchain. I am only suggesting a protocol that allowed for the externalized costs to be considered and a level playing field where tx fees , inflation , and demurrage were equally shouldered by Fidelity or anyone else. So go ahead and upload your virus signature, penis pictures, and spam to the network. I am perfectly fine if you wish to spend 7-10 dollars to do so per tx.
|
|
|
|
BitUsher
Legendary
Offline
Activity: 994
Merit: 1035
|
|
March 30, 2016, 02:38:45 AM |
|
So why aren't developers supporting classic, XT , or BU ?
because all (legitimate) devs are core devs?You are suggesting it is a popularity thing that developers are trying to pad their resume with the "principally important" implementation? This seems highly unlikely because ... 1) When Developers aren't being paid, they are principally concerned with working on items they are technically interested in or that make sense(are feasible). Bitcoin Core doesn't pay any salaries , and all other sources have no restrictions on what implication to work on , in fact the only implementation to bribe developers to work on it is Classic and perhaps Bitpay's Bitcore(not to be confused with Bitcoin core). 2) Developers aren't idiots , if they really believed in Classics roadmap than they would simply move over , miner would instantly agree as they aren't against classic per say, and than Classic would become the reference implementation with their resume padded on the right one. i cant tell if you're confirming or denying my statement Your statement was a bit ambiguous , so I answered it with the assumption that you suggested developers stayed with core because that was the only legitimate implementation to pad their resume. If you are insinuated that Gavin and Garzik aren't Experienced or "legitimate" developers , than I would have to disagree with you. The reason they appear to both work on core and classic is principally because their concerns and values aren't aligned with a majority of other developers. I.E... Gavin's own tests reflects that Classic can have a worst case scenario 60% node drop off rate, and he is fine assuming this risk where most other developers don't like this escalated form of centralization where we already have multiple centralization problems that we need to dig out of.
|
|
|
|
adamstgBit
Legendary
Offline
Activity: 1904
Merit: 1037
Trusted Bitcoiner
|
|
March 30, 2016, 02:45:57 AM |
|
|
|
|
|
billyjoeallen
Legendary
Offline
Activity: 1106
Merit: 1007
Hide your women
|
|
March 30, 2016, 02:54:19 AM |
|
You can't control what kind of data gets written to a censorship-resistant database. That would be censorship. Why can't you damn cripplecoiners get that through your heads? Who isn't being true to our values here?
You object to Fidelity getting fee discounts but not SegWit users getting discounts? You gripe about externalizing costs while you helped cause the value of my investment to lose 60% in the last 27 months. Kinda rich coming from you.
You can't have it both ways. Censorship-resistance means people are going to do stuff with their freedom that you don't like. We tolerate that because it mean we can do what they don't like. That's freedom, if you can't handle it, Bitcoin maybe isn't for you.
Classic helps mitigate the selfish mining advantage the Chinese get behind the Great Firewall. Faster block propagation means less of a mining Cartel for Fidelity et. al. with which to collude.
Ahh , you are reading into my statements and making some assumptions that I am not suggesting. I never said we should censor tx or data on the blockchain. I am only suggesting a protocol that allowed for the externalized costs to be considered and a level playing field where tx fees , inflation , and demurrage were equally shouldered by Fidelity or anyone else. So go ahead and upload your virus signature, penis pictures, and spam to the network. I am perfectly fine if you wish to spend 7-10 dollars to do so per tx. All you do by limiting transaction capacity is limit transaction capacity. You have no way of knowing if you've restricted cost-externalizing xactions more than legit xactions. It's possible that a higher percentage of xactions will be cost-externalizing on a near capacity network, because those are the only transactions that may make economic sense in a high fee environment. I'm not saying I know. I'm saying I don't know. can't know. and neither can you.
|
|
|
|
abercrombie
Legendary
Offline
Activity: 1159
Merit: 1001
|
|
March 30, 2016, 02:54:32 AM |
|
|
|
|
|
BitUsher
Legendary
Offline
Activity: 994
Merit: 1035
|
|
March 30, 2016, 03:08:26 AM |
|
All you do by limiting transaction capacity is limit transaction capacity. You have no way of knowing if you've restricted cost-externalizing xactions more than legit xactions. It's possible that a higher percentage of xactions will be cost-externalizing on a near capacity network, because those are the only transactions that may make economic sense in a high fee environment. I'm not saying I know. I'm saying I don't know. can't know. and neither can you.
Again , I'm not making a distinction between legit and illegitimate tx's. I want a robust network with dynamic tx fees where I really don't care if someone is attacking or spamming it. We don't have to know of the perfect ratio or balance to know we already started to have problems with node and mining centralization. More specifically, historical data suggests that over 0.5MB there are increasing centralization pressures and node drop off rate increased. Thus I have no problem with 100 or 100 MB sized blocks in principle .(In fact we will need extremely large blocks for the LN to be completely successful) My concern is rather than focus on problems which are of least concern , we should first at least reverse the trend of mining and node centralization or at minimum if we absolutely have to increase capacity now we should include aspects that allow us to scale better in the future like Segwit accomplishes.
|
|
|
|
adamstgBit
Legendary
Offline
Activity: 1904
Merit: 1037
Trusted Bitcoiner
|
|
March 30, 2016, 03:15:01 AM |
|
So why aren't developers supporting classic, XT , or BU ?
because all (legitimate) devs are core devs?You are suggesting it is a popularity thing that developers are trying to pad their resume with the "principally important" implementation? This seems highly unlikely because ... 1) When Developers aren't being paid, they are principally concerned with working on items they are technically interested in or that make sense(are feasible). Bitcoin Core doesn't pay any salaries , and all other sources have no restrictions on what implication to work on , in fact the only implementation to bribe developers to work on it is Classic and perhaps Bitpay's Bitcore(not to be confused with Bitcoin core). 2) Developers aren't idiots , if they really believed in Classics roadmap than they would simply move over , miner would instantly agree as they aren't against classic per say, and than Classic would become the reference implementation with their resume padded on the right one. i cant tell if you're confirming or denying my statement Your statement was a bit ambiguous , so I answered it with the assumption that you suggested developers stayed with core because that was the only legitimate implementation to pad their resume. If you are insinuated that Gavin and Garzik aren't Experienced or "legitimate" developers , than I would have to disagree with you. The reason they appear to both work on core and classic is principally because their concerns and values aren't aligned with a majority of other developers. I.E... Gavin's own tests reflects that Classic can have a worst case scenario 60% node drop off rate, and he is fine assuming this risk where most other developers don't like this escalated form of centralization where we already have multiple centralization problems that we need to dig out of. I agree that there are "legitimate" devs working on Classic or BU, but is Gavin and Garzik the only "legitimate" devs taking part in these projects?
|
|
|
|
adamstgBit
Legendary
Offline
Activity: 1904
Merit: 1037
Trusted Bitcoiner
|
|
March 30, 2016, 03:20:39 AM Last edit: March 30, 2016, 03:36:01 AM by adamstgBit |
|
... Gavin's own tests reflects that Classic can have a worst case scenario 60% node drop off rate, and he is fine assuming this risk where most other developers don't like this escalated form of centralization where we already have multiple centralization problems that we need to dig out of.
assuming worst case happens. what are the consequences of 60% node drop off rate? i'm going to get off like now ( its getting late ) but i'd also like to hear your thought on ~ what % of nodes would drop off due to 2MB Effective block size. we can chat about this tomorrow good night bitcoiners, hope you dont all go MAD from seemingly going in circles endlessly.
|
|
|
|
r0ach
Legendary
Offline
Activity: 1260
Merit: 1000
|
|
March 30, 2016, 03:36:46 AM |
|
Segwit soon + 2mb fork being scheduled by core = around 4mb blocks during 2017, there's nothing to discuss about block size unless you demand 8mb now.
|
|
|
|
BitUsher
Legendary
Offline
Activity: 994
Merit: 1035
|
|
March 30, 2016, 03:39:09 AM Last edit: March 30, 2016, 04:00:48 AM by BitUsher |
|
... Gavin's own tests reflects that Classic can have a worst case scenario 60% node drop off rate, and he is fine assuming this risk where most other developers don't like this escalated form of centralization where we already have multiple centralization problems that we need to dig out of.
assuming worst case happens. what are the consequences of 60% node drop off rate? Bitcoin becomes more insecure. I agree that there are "legitimate" devs working on Classic or BU, but is Gavin and Garzik the only "legitimate" devs taking part in these projects?
Sergio Lerner is talented but only does a bit of peer review on the side. The other ones lack experience with Bitcoin Development and/or Cryptography.
|
|
|
|
JimboToronto
Legendary
Offline
Activity: 4158
Merit: 4786
You're never too old to think young.
|
|
March 30, 2016, 04:12:01 AM |
|
Wow. I miss a couple of days due to a nasty lung infection (requiring antibiotics) and what do I see?
The Easter Bunny crawled back in his hole and we're right back where we've been for the last few weeks. Hovering around $416.
Yawn. If it was the morning I'd be making coffee. It's a few hours before my usual bedtime so I probably won't be able to get to sleep.
Boozing, toking and partying are definitely not on the agenda, so I should sentence myself to a night of bed rest and let the Clarithromycin do its work.
Thank gawd I live in a country with "socialized" healthcare. Imagine that. Taxpayers stealing profits from insurance corporations.
|
|
|
|
BitUsher
Legendary
Offline
Activity: 994
Merit: 1035
|
|
March 30, 2016, 04:19:10 AM Last edit: March 30, 2016, 10:24:16 AM by BitUsher |
|
but i'd also like to hear your thought on ~ what % of nodes would drop off due to 2MB Effective block size.
You should expect more nodes dropping off but not as much as classic. The 1.8 MB to 2MB Effective capacity increase from segwit places similar but less pressure as raising maxBlockSize limit. The reasons it places less pressure than a 2MB maxBlockSize limit is principally because these 2 reasons in the short term. 1) Average capacity limit is 1.8MB -2MB , not 2 MB, so less impact. 2) Reducing UTXO growth by making tx cost more that burden the UTXO set . This means that the attack on the network now that has clogged blocks with low txs could cost up to 4x more to accomplish. Too big of a UTXO set is directly what is crashing nodes due to lack of ram and RAM isn't cheap with VPS's. 3) Separating out signatures into a separate merkle tree allows older sigs to be pruned therefore these nodes have less bandwidth and storage needs. 4) Segwit separates out the signing of the input value which allows hardware wallets or embedded devices to function better 5) Removing the quadratic scaling of hashed data for verifying signatures makes scaling linear instead of quadratic on signature tree Longterm benefits for nodes - 1) Fraud proofs allow more pruned nodes to exist with higher level of security than SPV nodes 2) Fixing Tx malleability is critical to payment channels rolling out There are other benefits to segwit but these are the benefits to address your concern about nodes. I understand that one criticism for Segwit is that it increases the adversarial attack surface by up to 4x on the 2nd tree which is a valid criticism in it of itself but is out of context with items 2 and 5 above which are far more of a benefit than the risk of the increased attack surface.
|
|
|
|
adamstgBit
Legendary
Offline
Activity: 1904
Merit: 1037
Trusted Bitcoiner
|
|
March 30, 2016, 06:15:35 AM Last edit: March 30, 2016, 06:27:56 AM by adamstgBit |
|
but i'd also like to hear your thought on ~ what % of nodes would drop off due to 2MB Effective block size.
You should expect more nodes dropping off but not as much as classic. The 1.8 MB to 2MB Effective capacity increase from segwit places similar but less pressure as raising maxBlockSize limit. The reasons it places less pressure than a 2MB maxBlockSize limit is principally because these 2 reasons in the short term. 1) Average capacity limit is 1.8MB -2MB , not 2 MB, so less impact. 2) Reducing UTXO growth by making tx cost more that burden the UTXO set . This means that the attack on the network now that has clogged blocks with low txs could cost up to 4x more to accomplish. Too big of a UTXO set is directly what is crashing nodes due to lack of ram and RAM isn't cheap with VPS's. 3) Separating out signatures into a separate merkle tree allows older sigs to be pruned therefore these nodes have less bandwidth and storage needs. 4) Segwit separates out the signing of the input value which allows hardware wallets or embedded devices to function better 5) Removing the quadratic scaling of hashed data for verifying signatures makes scaling linear instead of quadratic on signature tree Longterm benefits for nodes - 1) Fraud proofs allow more pruned nodes to exist with higher level of security than SPV nodes 2) Fixing Tx malleability is critical to payment channels rolling out There are other benefits to segwit but these are the benefits to address your concern about nodes. I understand that one criticism for Segwit is that it increases the adversarial attack surface by up to 4x on the 2nd tree which is a valid criticism in it of itself but is out of concept with items 2 and 5 above which are far more of a benefit than the risk of the increased attack surface. thanks! this is very well laid out there's no doubt segwit has much promise. and i like how you agree there will be more or less the same amount of node dropping out due to more or less the same incress in bandwidth usage. here another possible downside to segwit ( i made it up ) not sure if it makes any sense probably not hard to handle... Introduces a new type of DOS attack (go-fish-wit-ddos) An attacker mines a segwit-block with 1000 transactions the network has not yet seen (The attacker creates these TX herself )The attacker has the witness data readily available. When other miners try to validate this block they will go through every single one of these TX and say "I don't have the witness data for this TX_ID, I have to call TCP::GetWitnessData( TX_ID ) aw yes this is valid" 1000 times
|
|
|
|
adamstgBit
Legendary
Offline
Activity: 1904
Merit: 1037
Trusted Bitcoiner
|
|
March 30, 2016, 06:25:03 AM Last edit: March 30, 2016, 06:54:32 AM by adamstgBit |
|
Segwit soon + 2mb fork being scheduled by core = around 4mb blocks during 2017, there's nothing to discuss about block size unless you demand 8mb now.
its not about the short term implications short term everyone should be fine with either segwit or 2MB its the longer term I dont like the sound of. I think LN is a drastic change and may prove to be non user friendly and impractical... ( not to mention not at all "free" its going to cost 2 BTC TX fees to open and close payment channels ) I need to be able to SELL the idea to poeple. if bitcoin is >1$ to TX on its hard to SELL poeple on the idea... digital money that is expensive to TX feels like broken digital money ( especially when every other alternative, crypto or otherwise, can offer lower fees/TX ) on the other hand, if we go with classic all we get is a theoretical drop in security ( less full nodes ) ( let's not kid ourselves my paper wallets are not less secure due to hobbyist nodes getting forced out of a GROWING ecosystem ) and i can continue to SELL the idea of truly frictionless money + we also get segwit!!! thats why we continue to discuss frictionless money thats the thing we are losing goign with core we lose the frictionless part AND we lose the money part i like these parts and i dont want to give them up so easily
|
|
|
|
Elwar
Legendary
Offline
Activity: 3598
Merit: 2386
Viva Ut Vivas
|
|
March 30, 2016, 07:07:33 AM |
|
Wow. I miss a couple of days due to a nasty lung infection (requiring antibiotics) and what do I see?
The Easter Bunny crawled back in his hole and we're right back where we've been for the last few weeks. Hovering around $416.
Yawn. If it was the morning I'd be making coffee. It's a few hours before my usual bedtime so I probably won't be able to get to sleep.
Boozing, toking and partying are definitely not on the agenda, so I should sentence myself to a night of bed rest and let the Clarithromycin do its work.
Thank gawd I live in a country with "socialized" healthcare. Imagine that. Taxpayers stealing profits from insurance corporations.
In the US, to pay for healthcare the government steals from every citizen. A tax on just being alive.
|
|
|
|
adamstgBit
Legendary
Offline
Activity: 1904
Merit: 1037
Trusted Bitcoiner
|
|
March 30, 2016, 07:17:10 AM |
|
Wow. I miss a couple of days due to a nasty lung infection (requiring antibiotics) and what do I see?
The Easter Bunny crawled back in his hole and we're right back where we've been for the last few weeks. Hovering around $416.
Yawn. If it was the morning I'd be making coffee. It's a few hours before my usual bedtime so I probably won't be able to get to sleep.
Boozing, toking and partying are definitely not on the agenda, so I should sentence myself to a night of bed rest and let the Clarithromycin do its work.
Thank gawd I live in a country with "socialized" healthcare. Imagine that. Taxpayers stealing profits from insurance corporations.
In the US, to pay for healthcare the government steals from every citizen. A tax on just being alive. you know what i do? i smoke and drink, to make sure i get my monies worth.
|
|
|
|
edgar
Legendary
Offline
Activity: 1848
Merit: 1001
|
|
March 30, 2016, 08:18:16 AM |
|
|
|
|
|
Gyrsur
Legendary
Offline
Activity: 2856
Merit: 1520
Bitcoin Legal Tender Countries: 2 of 206
|
|
March 30, 2016, 09:11:18 AM |
|
matt == diva
|
|
|
|
BitUsher
Legendary
Offline
Activity: 994
Merit: 1035
|
|
March 30, 2016, 10:37:32 AM Last edit: March 30, 2016, 10:48:11 AM by BitUsher |
|
Introduces a new type of DOS attack (go-fish-wit-ddos) An attacker mines a segwit-block with 1000 transactions the network has not yet seen (The attacker creates these TX herself )The attacker has the witness data readily available. When other miners try to validate this block they will go through every single one of these TX and say "I don't have the witness data for this TX_ID, I have to call TCP::GetWitnessData( TX_ID ) aw yes this is valid" 1000 times
This attack isn't possible with the way segwit is constructed and comes from a lack of understanding . If the witness root hash doesn't match what is in the coinbase the block will be rejected by the node. At no point will each individual tx be requesting witness data . Additionally , If we are going to speak more broadly about pros and cons segwit remove all malleability attacks which is huge. Segnet 4 rolled out (getting closer to segwit final RC), spin up a node and test away-- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012595.htmlThe exciting thing is it now supports LN app deployment and testing .
|
|
|
|
|