Obviously, running your code does not always end up with "segmentation fault", it is only a possibility.
int main()
{
[b]int array[10]; [/b]
array[11] = 0;
printf("stick with core\n");
}
Oops, I was wrong. Because you put the "array" array on the stack, there are no chances for "segmentation fault". Peter TRoll 'developer' #REKT  The array is neither static nor in a function, so its not on the stack. More likely ( dependent on your setup) its pre-allocated in the programs data section. The fact that you dont core any time is down to blind luck. int main() { ... } is not a function? Look again! (gdb) run
Starting program: /home/valiz/petertroll
Breakpoint 1, main () at petertroll.c:6
6 array[11] = 0;
(gdb) info registers rsp
rsp 0x7fffffffe2b0 0x7fffffffe2b0
(gdb) print &array[11]
$2 = (int *) 0x7fffffffe2dc
(gdb) l
1 #include <stdio.h>
2
3 int main()
4 {
5 int array[10];
6 array[11] = 0;
7 printf("stick with core\n");
8 }
9
you are correct. for some reason i didnt see that... |
|
|
|
Obviously, running your code does not always end up with "segmentation fault", it is only a possibility.
int main()
{
[b]int array[10]; [/b]
array[11] = 0;
printf("stick with core\n");
}
Oops, I was wrong. Because you put the "array" array on the stack, there are no chances for "segmentation fault". Peter TRoll 'developer' #REKT The array is neither static nor in a function, so its not on the stack. More likely ( dependent on your setup) its pre-allocated in the programs data section. The fact that you dont core any time is down to blind luck. |
|
|
|
21 million reasons for 'thought re-alignment". It will be interesting to hear him reason out his change of view.
You are just finding ways of attacking individuals which does not benefit anyone. Being willing to listen someones arguments is equivalent to an attack now, is it? Thats what we used to call a debate. You have a pretty perverse understanding of it. |
|
|
|
Do you even realize that the long term outcome of Lightning (the Holy Graal of Core folks) would be to massively reduce the amount of transaction fees versus an on-chain scaling?
Wait, what? Core is simultaneously accused that they want "higher fees" or "fee competition" and now accused for "wanting to massively reduce fees with lightning". Please decide what core wants. I think you are being deliberately obtuse - surely you get this? There's nothing wrong with LN. Nothing fundamental anyway - if bitcoin really wants to get to visa like adoption ( and i still think thats a bad idea) then LN is the only game in town. But it needs to play on a level playing field with the rest of the users - i.e those who wish to use the blockchain directly. Blockstreams intention is to artificially constrict supply so as to force smaller payments to LN, irrespective of whether it offers them a better service or not. Miners get higher fees, but fewer of them. The bulk of the volume, low fees go to LN What I'm saying is that it needs to survive in an open market. Not some sort of Soviet style managed/protected environment. |
|
|
|
High fees = "fuck core devs"
Low fees = "fuck core devs"
I'm satoshi fanclub, and I fully approvre this message.  |
|
|
|
21 million reasons for 'thought re-alignment". It will be interesting to hear him reason out his change of view. |
|
|
|
Big banks are getting behind Bitcoin "Classic" fork. That is their next move.
Hmm... Dont you usually follow such a statement with "Mooooonn!! This is gentlemen....", etc. etc. < train.gif > < rocket.gif > |
|
|
|
I answered this earlierSensible bounds on memory usage per tx or time based rules mitigate or solve this entirely. If you are putting so much into a tx, then you are exceeding isStandard() rules anyway. There is currently no solution and you are wrong. XT introduced a per transaction limit (if I'm correct). Core will address this via BIP 143 ,which is an actual improvement unlike the workaround in XT, and a limit. However this is node policy, miners can still create a transaction that would take too long to validate and that would harm the network. I beg to differ, I think you are wrong when you suggest "there is no solution". Even the text of BIP143 describes what can be done - it says its non-trivial, not impossible. Their biggest objection is the hard fork ( as usual). But as I described, this can be mitigated by a refined version of the XT fix. Bip143 is part of segwit. Its part of a 2000+ line change to implement it. When we are ready for segwit, yeah fine. XT does not have a per tx limit - its a per block limit. It strives to ascertain rational limits to allow most tx's through but to limit obviously vexatious ones. |
|
|
|
Why would be only 5-10, or only 500 nodes? There is no factual data to support that claim at all.
Everyone can have a p2p client that deals with 10kb/sec, has 100 mb storage requirements, needs 1 small cpu and 256mb ram. As you go up and up in hw requirements, cost goes up, "volunteers" go down - even if userbase goes up. As you hit datacenter level requirements the number of "volunteers" starts dropping significantly because costs start running in the 5 digit, then 6 digit category and eventually you'll be paying millions. Some of us remember 8 bit CPUs running at 4Mhz with 1k of RAM and software stored on audio cassettes. Hard drives were just something you read about. The first one I actually had (nearly 10 years later) was 40MB In the past 10 years, I have seen 10 racks of servers in a server room disappear into a handful of Virtual hosts. I'm currently running a full node on Amazon's smallest, weakest instance type. Their cost for storing the blockchain as it currently stands is on the order of $5/month. These are issues we should not be worrying about until they are measurably becoming an issue. Like regularly full blocks already *are* This. (My first hard drive was 10 MB, btw.) An old ferguson cassette tape recorder attached to a Sinclair zx81 2000 bits per second, with about 500kb per side. I still have an old 7 track tape from an IBM on the wall of my office. Weighs 3kgs and holds 1.1Mb (edit: I rescued it from being scrapped in a bank i was working at, never actually used one  ) |
|
|
|
Are you referring to unbounded hashed bytes for sigops? Why not bound them? And are all these transactions isStandard()?
Example transaction.What kind of transaction could take that long to validate? a large transaction with a lot of SIGHASH_ALL signatures, basically
The problem is that the algorithm used for SIGHASH_ALL is O( n2 ), and requires that you hash 1.2 GB of data for a 1 MB transaction.
I answered this earlierSensible bounds on memory usage per tx or time based rules mitigate or solve this entirely. If you are putting so much into a tx, then you are exceeding isStandard() rules anyway. |
|
|
|
Maybe you missed that highlighted bit. You are giving me a list of those in involved in creating the approach, and attempt to pass it off as a list of those who support it.
So let's take the development away from a group with several years of experience and assign it to people with much less experience or none? In what world does that make sense? I dont think that was the point we were making. But as you mention it, it is an open source project. Anyone can make a contribution and if it passes review it can be accepted. Are you saying that the *only* talented developers in the world work with core? That is utter cock. There are plenty of talented developers who can get involved. But its a moot point - most of the good contributors would continue with whatever gained consensus. Unless they felt the politics is more important than the code. In which case they are welcome to leave. |
|
|
|
Thanks for that link. It's interesting how luke-jr was considered at this time I've read many of the developer logs from Bitcoin and I must say I'm surprised this hasn't really come to a head earlier. If you read luke-jrs response to pretty much anything he disagrees with he does the "you do that and I'm not going to mine it" approach. "If you do that I'm going to fork the chain" . Basically turning every minor problem into a major one and using his pool as his body guard.
Does anyone actually think Luke-Jr is a positive presence? Attacking other currencies, filing false claims to hosts, inserting religious text into Bitcoin and finally holding Bitcoin development team to ransom to stall development? With that sort of positive presence I'm glad he's over here rather than focusing on SolidCoin. Tongue
Now, can you explain why GregMaxwell handed him over the key to his Push Access? Have a look at his contributions to PR#6 on Bitcoin Classic. Core can keep him. |
|
|
|
That is a list of people who support Core's scaling roadmap. The "incisive point" is that you are a liar that claimed "nobody wants" Core's approach. We, the undersigned, support the roadmap in Capacity increases for the Bitcoin system. We have been working on scalability for several years within the Bitcoin Core project and consider this the best possible continuation of our efforts. The list of core contributers is much longer and may be found at github. Maybe you missed that highlighted bit. Do you have a list of turkeys who vote for Christmas? You are giving me a list of those in involved in creating the approach, and attempt to pass it off as a list of those who support it. Of course they support it, you numpty. |
|
|
|
Thats a list of core contributors. Well done. I'm sure you meant to make an incisive point with that cut'n'paste, and as soon as I see it I will be sure to "+1" it for you.
I guess he wanted to say: Look here, so many people did sign the roadmap. You must be a liar, because -- fuck you fuck you get out of bitcoin fork away let's me and my super-rich friends play alone you poor noob gavinist and toominist and statist and leftist.
I imagine his efforts on the keyboard are split roughly 50% typing and 50% spitting |
|
|
|
So whataya got for me?
A list of Core supporters that prove you are liar: Adam Back Alex Morcos Aaron Voisine Ben Davenport Ben Gorlick Bram Cohen Bryan Bishop BtcDrak Charlie Lee Christian Decker Cøbra Cory Fields Craig Watkins Daniel Daniel Kraft David A. Harding David Vorick Dev Random DexX7 Douglas Huff Eric Lombrozo Glenn H Tarbox Gregory Maxwell Gregory Sanders James Knobend Johnathan Corgan Johnson Lau Jonas Schnelli Jouke Hofman Lawrence Nahum Luke Dashjr Mark Friedenbach Eric Martindale Manuel Aráoz Marco Falke Matt Corallo Midnight Magic Michael Ford Nicolas Bacca Nicolas Dorier Obi Nwosu Patrick Strateman Pavel Janik Peter Todd Pieter Wuille Randy Waterhouse Rodolfo Novak Ruben de Vries Suhas Daftuar Theymos Thomas Kerin Wang Chun Warren Togami Wladimir J. van der Laan Please pout more about now "Nobody Wants" Core's scaling roadmap. It's funny! Thats (largely) a list of core contributors. Well done. I'm sure you meant to make an incisive point with that cut'n'paste, and as soon as I see it I will be sure to "+1" it for you. |
|
|
|
The core development team had more than enough time now to design a version of Bitcoin that allows scalability.
Core has already designed "a version of Bitcoin that allows scalability." Is that the one that Nobody Wants tm? Nobody Wants a contentious hard fork and subsequent catastrophic consensus failure, except XT/Unlimited/Classic dead-enders (but you guys don't matter, because Bitcoin is not a democracy). The people who matter support Core. Here, have some Fact Welfare you poor, low-information Toominista. https://bitcoin.org/en/bitcoin-core/capacity-increasesWhy don't you follow your role model Mike Hearn's example, and ride off into the sunset? You've got the whining part down, now you just need to GTFO.  You are always so angry. I love that about you.... So whataya got for me? Contentious fork? No such thing. It either forks with over 75% behind it or it doesn't happen. Just coz you are crying does not make it contentious. Catastrophic Consensus Failure? See first point. You can swim against the tide all you like, bitcoin will move on without you. Bitcoin is not a democracy? This does not equal "Developer X decides the future" Its consnesus - what the majority follow is what becomes the standard. you cant influence it or subvert it. People who matter support core? Not anymore. They had their chance and blew it. The market is tired of their procrastination and buying time waiting for their overly complex solutions. Whining? Me? |
|
|
|
The core development team had more than enough time now to design a version of Bitcoin that allows scalability.
Core has already designed "a version of Bitcoin that allows scalability." Is that the one that Nobody Wants tm? |
|
|
|
No, it is not. 2 MB blocks could be designed so that they have nodes forking everywhere around the world (SegWit is safer). Good luck trusting a broken network.
Are you referring to unbounded hashed bytes for sigops? Why not bound them? And are all these transactions isStandard()? |
|
|
|
it’s possible to construct a transaction that takes up almost 1MB of space and which takes 30 seconds or more to validate on a modern computer (blocks containing such transactions have been mined). In 2MB blocks, a 2MB transaction can be constructed that may take over 10 minutes to validate which opens up dangerous denial-of-service attack vectors. Other lines of code would need to be changed to prevent these problems. sauceThis is a known protocol design bug: signatures were defined in such a way that the cost of validating a transaction with N signatures is proportional to N 2 rather than N. It has a known simple solution: limit the number of inputs of a transaction to some reasonable value, say 20 or 100, independent of the block size limit. That will keep the cost of verifying one transaction bounded, and will inconvenience only a few users, by forcing them to break any big transaction into a chain of smaller ones. IIRC, BiotcoinXT included this simple solution. Hopefully it will be included in Classic too. XT simply made a more accurate count of the number of ECDSA ops to validate the block,( and put a proportional limit on this), but more importantly estimated the amount of *data* needed to do so. This is where the real performance hit was - the block quoted took 1.2Gb to store the hashes. An average single core cpu can do around 10K sig hashes per second with libsecp258, so sigops in of themselves is not the issue. So it limited sigops to 80k for a 8mb block, but crucially, limited no. of bytes needed to calc. sig hashes ( up to 1.3Gb for an 8mb block) where previously this was unlimited. These are not difficult problems to solve. There just needs to be a will. I think core much rather keep the problem so they can point to it and say "Look what will happen!!" |
|
|
|
|
Show Posts
