I know, I was kidding
Sztorc shown to be arrogant and at the same time he proved to be extremely stubborn in denying a plain fact.
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
not knowing any details of exactly how all these private blockchains are being constructed makes it hard to discuss. but afaik, most will depend on a POS mechanism to avoid the hassle of POW. what this means is that private institutions will then always be periodically bringing their keys online to sign blocks. that's a big security concern. who's responsibility will it be if the keys get compromised? what's to stop an institution from signing both sides of a fork in their desire to capture tx fees from both sides of the fork; the "nothing at stake" problem. IOW, the regulation around compromised keys and the enforcement of foul play should be quite a spectacle.
@Norway and I (and others) had an interesting interaction today with shill-in-residence on the Bitcoin Classic Slack, "jamesshilliard". He went through the usual arguments about the Classic nodes all being cloud hosted so basically sybil nodes. I pressed him about the DDoS attacks and of course he claimed that the DDoS was fictitious.
My home node has been knocked offline like clockwork over the past two weeks, so I have no doubt about it and direct first-hand experience. Of course that was not enough for James and since I had time today, I told him I would get him a Wireshark capture if that would please him. Of course he challenged (taunted?) me to do it.
So sure enough after 46 minutes of being online, my Classic node was hammered and my home internet taken down again, just like always. But this time I had the whole thing captured.
I provided Shilliard with the complete PCAP files, luckily they compressed well and could be sent on Slack.
Same basic attack structure as always. Node connects and does the version command while reporting its version as "Why? Because fuck u, that's why".
Then later a DNS amplification attack. They spoof your node's address to open DNS resolvers and do a TXT query against qrtor.ru (in this instance). The response to that query is around 3800 bytes and just giant strings of "XXXXXXXXXXXXXXXXXX".
Anyway, it was quite satisfying to be able to show James we are not making this up and perhaps if it weren't for the DDoS attacks we would not have to rely so heavily on Amazon and elsewhere to bring up nodes.
It seems to be an all-too-common and convenient copout during discussions to just deny the DDoS attack exists, even Greg Maxwell says it. So if anyone encounters any deniers, let me know and I can provide them with the full PCAP files.
My home node has been knocked offline like clockwork over the past two weeks, so I have no doubt about it and direct first-hand experience. Of course that was not enough for James and since I had time today, I told him I would get him a Wireshark capture if that would please him. Of course he challenged (taunted?) me to do it.
So sure enough after 46 minutes of being online, my Classic node was hammered and my home internet taken down again, just like always. But this time I had the whole thing captured.
I provided Shilliard with the complete PCAP files, luckily they compressed well and could be sent on Slack.
Same basic attack structure as always. Node connects and does the version command while reporting its version as "Why? Because fuck u, that's why".
Then later a DNS amplification attack. They spoof your node's address to open DNS resolvers and do a TXT query against qrtor.ru (in this instance). The response to that query is around 3800 bytes and just giant strings of "XXXXXXXXXXXXXXXXXX".
Anyway, it was quite satisfying to be able to show James we are not making this up and perhaps if it weren't for the DDoS attacks we would not have to rely so heavily on Amazon and elsewhere to bring up nodes.
It seems to be an all-too-common and convenient copout during discussions to just deny the DDoS attack exists, even Greg Maxwell says it. So if anyone encounters any deniers, let me know and I can provide them with the full PCAP files.
he's smelled bad ever since i had a run-in with him Fall 2014 after he started pumping Truthcoin on Twitter. once i guided him into a corner he couldn't get out of, he terminated our twitter convo with a similar, "you don't know what you're talking about!".
[doublepost=1457397405][/doublepost]
first off, nice documentation on the attack. is there any way to mitigate it? my understanding is there is nothing one can do except report it to your ISP, which is basically useless.
second, don't waste your time with that troll. i have already wasted plenty. he's disingenuous and will eat up your time needlessly. what a shit; everyone is seeing that "Why? Because fuck u, that's why" in their logs proving there is a ddos. another under-handed tactic by Core and their minions.
Yup, its not business it's personal - madness, that is.Alas it can't really be proven he is a shill ... <snip> ...
Mental it is then
the other thing about constantly using one's key to sign off on blocks is that you're revealing the public key. what with this potential looming threat of quantum computing, who takes responsibility for the first QC attack on a banks assets? all these idiots who've signed off on coin support for Core over on Bitcoinocracy are begging for a hack one day. wouldn't that be something?
Has there been any discussion about using interleaved blocks?
Of course, some details about fungibility between the different interleaves and closing some attack vectors, but if the 1MB limit is really so important (it isnt technically), you can make a hardfork where N different interleaves are mined. So there would be N different parallel chains, each offset by 10 minutes/N. This way, each interleave gets the full 10 minutes for mining and propagation, removing all "objections" to larger blocks/faster blocks, etc.
I think each would need to be mined independently and just have a convention so (txid mod N) determines which interleave a tx gets mined on.
Using interleaves, the number N can be changed as tx levels require it. But really, I dont see what the big technical issue is with 1MB. Just change to 2MB and 5 minute blocks to get an immediate 4x capacity increase. then a 10x interleave for a total 40x increase. That would buy enough time for truly solving the scalability. Another 2x could be gained by using the canonical numbering that iguana uses, so now it approaches 100x capacity increase. And with the bundle approach, the time to do everything will gradually get faster and faster over the years as CPU's get more cores faster than blockchain size increases.
Of course, some details about fungibility between the different interleaves and closing some attack vectors, but if the 1MB limit is really so important (it isnt technically), you can make a hardfork where N different interleaves are mined. So there would be N different parallel chains, each offset by 10 minutes/N. This way, each interleave gets the full 10 minutes for mining and propagation, removing all "objections" to larger blocks/faster blocks, etc.
I think each would need to be mined independently and just have a convention so (txid mod N) determines which interleave a tx gets mined on.
Using interleaves, the number N can be changed as tx levels require it. But really, I dont see what the big technical issue is with 1MB. Just change to 2MB and 5 minute blocks to get an immediate 4x capacity increase. then a 10x interleave for a total 40x increase. That would buy enough time for truly solving the scalability. Another 2x could be gained by using the canonical numbering that iguana uses, so now it approaches 100x capacity increase. And with the bundle approach, the time to do everything will gradually get faster and faster over the years as CPU's get more cores faster than blockchain size increases.
@cipherdoc Thanks much, and good advice about Shill-i-ard! I feel like that is a rather effective strategy of just wasting everyone's time with the same arguments. I see this on Slack all too often. I'm surprised at how many small-blockers are just stationed there, ready to start the same circular argument. Almost like we should create a shill FAQ. Or perhaps a directory of shills and whether they are worth talking to.
In regards to the attack itself, there is nothing you can do about it unless you have real DDoS mitigation in place, and that would need to be done professionally and upstream of your network. No real options to even trace it back since open resolvers are being used. My guess is the version "Why? ..." is just to taunt people. If we actually tried to filter that, the attacker would just get rid of it. Also they could easily use a botnet to query versions and there would be no stopping it. The host that queried me today as well as the domain involved were all Russian.
In unrelated Seg-Wit news, somebody on /r/btc linked to this post by Jonathan Toomin explaining why seg-wit is a very bad idea. I have never read it explained quite so clearly and I feel this is really important to get out.
I would be curious to hear what people think about this. The trojan horse of seg-wit makes me feel more and more worried by the day. It seems like there have been no considerations of other possible ways to get the benefits of seg-wit through other approaches. Additionally, all of the public articles put out about scaling through a hard-fork seem to just say "seg-wit is great, but let's do this first". It would be good to get some analysis if seg-wit is in fact so great, or if people are bypassing that argument simply for convenience right now.
In regards to the attack itself, there is nothing you can do about it unless you have real DDoS mitigation in place, and that would need to be done professionally and upstream of your network. No real options to even trace it back since open resolvers are being used. My guess is the version "Why? ..." is just to taunt people. If we actually tried to filter that, the attacker would just get rid of it. Also they could easily use a botnet to query versions and there would be no stopping it. The host that queried me today as well as the domain involved were all Russian.
In unrelated Seg-Wit news, somebody on /r/btc linked to this post by Jonathan Toomin explaining why seg-wit is a very bad idea. I have never read it explained quite so clearly and I feel this is really important to get out.
I would be curious to hear what people think about this. The trojan horse of seg-wit makes me feel more and more worried by the day. It seems like there have been no considerations of other possible ways to get the benefits of seg-wit through other approaches. Additionally, all of the public articles put out about scaling through a hard-fork seem to just say "seg-wit is great, but let's do this first". It would be good to get some analysis if seg-wit is in fact so great, or if people are bypassing that argument simply for convenience right now.
How about implications for Canada of the central bank issuing their own crypto currency? See http://www.pymnts.com/news/2015/central-bankers-after-their-own-bitcoin
Last edited:
@jtoomim isn't saying anything i haven't been saying for a while now. i agree with him. i don't like SW b/c it preferentially favors LN multisigs thru a centrally mandated pwuille/gmax 75% discount. once SW was ready, to them, all of a sudden 4MB blocks became OK whereas prior to December, anything >1MB was the devils brew.
also, that wide open script versioning will be exploited by the inflationists, mark my words.
albin
Active Member
- Nov 8, 2015
- 931
- 4,008
Today I happened to read a clickbait article with general pop advice for avoiding relationship dysfunction, and everything they advised not to do sounded exactly like small blockers to me!
@dlareg
the fastest way to understand SW is to understand the math here: https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-308#post-11291
you need to scroll back and forward several pages to get a full understanding. i've been tweeting incessantly about it on twitter as well.
the fastest way to understand SW is to understand the math here: https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-308#post-11291
you need to scroll back and forward several pages to get a full understanding. i've been tweeting incessantly about it on twitter as well.
@cypherdoc Thank much for the links! I remember when you were posting about that, and I will go back and re-read. I'm also a fan of your Twitter interactions .
I guess what never stuck with me about seg-wit was this future 4X on-chain scaling penalty it creates. I guess that all escaped me. And now I'm seeing what a devious little "feature" it is. So I guess my obliviousness to that situation is what has caused me to re-sound the alarm that you've been sounding for so long. What a huge mess and strategic powerplay this whole Core roadmap really is! They are not messing around.
.I guess what never stuck with me about seg-wit was this future 4X on-chain scaling penalty it creates. I guess that all escaped me. And now I'm seeing what a devious little "feature" it is. So I guess my obliviousness to that situation is what has caused me to re-sound the alarm that you've been sounding for so long. What a huge mess and strategic powerplay this whole Core roadmap really is! They are not messing around.
albin
Active Member
- Nov 8, 2015
- 931
- 4,008
The brutal irony I'm seeing in all the "your coffees shouldn't go on the blockchain" / "Bitcoin is strictly for censorship resistance" arguments is that historically many governments have outlawed coffee at various times!
79b79aa8
Well-Known Member
- Sep 22, 2015
- 1,031
- 3,440
Did you see this post: https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-398#post-13849
There is a place for shared, permissioned ledgers. The use cases are just different than for a public blockchain like bitcoin's. It is not a case of one vs. the other.
Some advantages of permissioned ledgers:
(a) ability to directly digitize existing asset classes without going through network issued currency, for use cases that need not involve trade (see IBM's implementation).
(b) privacy: some transactions/contracts not suitable to be encoded in a public chain, e.g. ones that would reveal sensitive info. to competitors.
(c) legal and practical obstacles to settling trades of securities and similar assets on a public chain whose security is provided by unknown parties in many jurisdictions (miners).
Obvious disadvantages of private chains: not trustless, less secure.
Permissioned legders are an interesting data structure + network architecture that will certainly find some business uses. But they are just a mere by-product of the far-reaching, mind-boggling invention bequeathed by Satoshi.
@dlareg
the easiest way to think about the SW math is that all assumptions flow from what a core dev central planner really believes is the maximum blocksize "relay-able" across the network despite what they have been claiming over the last year; that blocksize which he believes the network can handle w/o excessive orphaning. in the SW case conceptualized by pwuille and gmax that Magic Number is now 4MB! WTF happened to 1MB? anyways, once you fix that number, then you determine what actual blocksize you want permanently embedded in the blockchain as storage; in this case they want to keep the established 1MB to allow for a SF so that old nodes simply cannot refuse to adopt SW tx's. nvm that their security will forcefully get downgraded to ANYONECANSPEND SPV node levels where you can't check the validity of txs coming through your node. so to get from 4MB down to 1MB you need to multiply by0.75 0.25; that's where the 75% discount comes from. hence the formula, a+b/4<=1MB. they could've just as easily said they believed that the maximum blocksize relay-able by the network is 2MB, then they'd have to multiply by 0.5 for a 50% discount, or a+b/2<=1MB. Or even a+b<=1MB and no discount; but that might be too fair to people wanting to do normal p2pkh txs. Can't have that.
in any case, these discounts preferentially favor/promote LN multisigs since they by definition involve larger, more expensive signatures. Blockstream knows that to get ppl to use LN, they need to offer them something; like a discount for the larger more expensive signatures required to setup a payment channel. otherwise ppl might not use them since most tx's are charged based on satoshis/byte. plus, they have to pull the wool over the eyes of miners and full nodes by obfuscating the fact that they will have to transmit all this extra signature data at a discount bytelling feeding them bullshit like they get to consolidate the UTXO set at a discount (!) and that a functional LN will afford them 100x the current tx fees that they are currently getting. lol.
the easiest way to think about the SW math is that all assumptions flow from what a core dev central planner really believes is the maximum blocksize "relay-able" across the network despite what they have been claiming over the last year; that blocksize which he believes the network can handle w/o excessive orphaning. in the SW case conceptualized by pwuille and gmax that Magic Number is now 4MB! WTF happened to 1MB? anyways, once you fix that number, then you determine what actual blocksize you want permanently embedded in the blockchain as storage; in this case they want to keep the established 1MB to allow for a SF so that old nodes simply cannot refuse to adopt SW tx's. nvm that their security will forcefully get downgraded to ANYONECANSPEND SPV node levels where you can't check the validity of txs coming through your node. so to get from 4MB down to 1MB you need to multiply by
in any case, these discounts preferentially favor/promote LN multisigs since they by definition involve larger, more expensive signatures. Blockstream knows that to get ppl to use LN, they need to offer them something; like a discount for the larger more expensive signatures required to setup a payment channel. otherwise ppl might not use them since most tx's are charged based on satoshis/byte. plus, they have to pull the wool over the eyes of miners and full nodes by obfuscating the fact that they will have to transmit all this extra signature data at a discount by
Last edited:
- Dec 16, 2015
- 2,806
- 6,088
If you guys keep posting such good information I may never go to sleep. Or I may have to resort to alcohol like @Norway
Anyway, just wanted to make a prediction: One day I sadly will have to stop posting on this list. If that day comes, you know where to look for me:
Anyway, just wanted to make a prediction: One day I sadly will have to stop posting on this list. If that day comes, you know where to look for me:
@cypherdoc Thanks again! I didn't realize the .25 factor came from the 4 MB assumption... what a dreadful hack. To take an elegant system like Bitcoin and retrofit it with a rushed "scaling solution" like this is a disgrace, an utter disgrace. And then trying to shoehorn this change as a soft-fork. It's a hack within a hack. I wonder how long they've been planning this?
@Peter R I couldn't think of a more qualified person to attend. I wish you luck.
Some thought that pop into my mind are Money is Memory (the blockchain is memory and private keys are your proof)
oops, just corrected a typo in that last post; i meant multiply by 0.25 instead of what i had originally as 0.75.
Last edited:
