I would gladly use Bitcoin-core instead of BU if ONLY Bitcoin Core had a GUI setting for me to increase the maximum block size my full node is willing to accept AND a GUI setting to disable and not relay SegWit transactions. Then I would happily keep using Core because I have a certain level of trust towards the Core's codebase.
https://bitcoinec.info/Seems promising! THANKS MATE! edit: from their FAQ it seems they have segwit included in that implementation. I can't accept this. Perhaps I should make a branch of BitcoinEC that would allow user to disable SegWit relaying? Also, I actually don't care about emergent consensus. I would just set my node to accept blocks smaller or equal to 4 MiB right now and later increase the limit manually. Also should the longest chain include blocks larger than what my node is willing to accept the wallet should alert me that I should consider increasing that limit. |
|
|
|
|
I would gladly use Bitcoin-core instead of BU if ONLY Bitcoin Core had a GUI setting for me to increase the maximum block size my full node is willing to accept AND a GUI setting to disable and not relay SegWit transactions. Then I would happily keep using Core because I have a certain level of trust towards the Core's codebase.
|
|
|
|
curl (program) has a way of passing arguments through a file instead of a command line. Something like "curl -d @filename ...". I recall being able to easily pass megabyte-long JSON-RPC queries without a problem by writing them first into a temporary file. This wasn't anything Bitcoin-related, it was for a closed-source load-balancers from F5 Networks.
Your architecture certainly looks original, but I probably just don't understand your constraints well enough. popen() is just a wrapper around pipe(), fork() and exec() calls, seems like using them directly would make the whole thing easier to understand.
I'm writing this on a decidedly non-POSIX tablet, so I can't even look up my old notes.
Ok thanks for the input. Here are my architectural constraints. I want to keep the program single-threaded on purpose. It's way easier to develop, maintain, debug and understand a single-threaded program than a multi-threaded one. I use a main loop and epoll to listen for incoming TCP connections from localhost. The wallet manager has a CLI over TCP/IP. The program has to be self-contained and with only trivial dependencies so I am not using any big phat libraries and what not. I use SIGALRM to interrupt epoll_pwait for example so that the main loop of my program could maintain a stable FPS. The latter makes it very important to avoid potentially indefinite blocking caused by some system calls. The project has to run on popular Linux platforms so I try to keep it POSIX compliant. I believe that I can still taste the benefits of parallelism even though my program is single-threaded. I achieve it with the help of OS and I'd rather spawn a new, independent and isolated process than a new thread to perform tasks in parallel. Curl program can actually indeed get its request data and config parameters from stdin. I believe the filename would be - in that case (minus sign indicates stdin). I was sort of hoping that popen provides me more isolation from the hassles that come with multithreading. For example, I assume that popen does not expose me to file/socket descriptor leaking and various signal handling related pitfalls in multithreaded context. If I was to use fork and pipe approach I'd have to disable signal handlers in the child process and close the sockets and what not (gets real messy real fast). So that's why I'm using popen (with & in the end of command line). But if this is a fallacy I'd be glad if you enlightened about that. Below is the problematic function: void TREASURER::bitcoin_rpc(const char *method, const nlohmann::json* params) {
/*
* Instead of making a blocking cURL request here we are spawning a child
* process with popen so that we can carry on with the main program while
* the request is being executed. When the child process finishes it will
* connect back to the main server providing us the response from Bitcoin RPC.
* This clever trick achieves asynchronous HTTP requests without using threads
* in our main process.
*/
if (manager->get_global("auth-cookie") == nullptr) {
manager->bug("Unable to execute Bitcoin RPC '%s': cookie not found.", method);
return;
}
nlohmann::json json;
json["jsonrpc"] = "1.0";
json["id"] = method;
json["method"] = method;
if (params) json["params"] = *params;
else json["params"] = nlohmann::json::array();
//std::cout << json.dump(4) << std::endl;
std::string cfg;
cfg.append("--url http://127.0.0.1:8332/\n");
cfg.append("--max-time 10\n");
cfg.append("-u ");
cfg.append(manager->get_global("auth-cookie"));
cfg.append(1, '\n');
cfg.append("-H \"content-type: text/plain;\"\n");
cfg.append("--data-binary @-\n");
cfg.append(json.dump());
std::string hex;
str2hex(cfg.c_str(), &hex);
std::string command = "printf \"%s\" \"";
command.append(hex);
command.append(1, '\"');
command.append(" | xxd -p -r ");
command.append(" | curl -s --config - ");
command.append(" | xargs -0 printf 'su\nsend ");
command.append(std::to_string(id));
command.append(" %s\nexit\nexit\n'");
command.append(" | netcat -q -1 localhost ");
command.append(manager->get_tcp_port());
command.append(" > /dev/null 2>/dev/null &");
FILE *fp = popen(command.c_str(), "r"); // Open the command for reading.
if (!fp) manager->bug("Unable to execute '%s'.\n", command.c_str());
else {
pclose(fp);
manager->vlog("Bitcoin RPC ---> %s", method);
}
}
The above code fails if the command length is too long. Strangely, the maximum length of the command is not equal to ARG_MAX. It's some 30 times less than that  If I could figure out how to programmatically get the real maximum command line length popen can handle then I could implement a fallback for really long Bitcoin RPC arguments (such as raw transaction hex). The fallback would first call makefifo to create a named pipe in /tmp , then spawn a curl process reading from that fifo with popen (& in the end) and then write the Bitcoin RPC into the fifo from the main program. |
|
|
|
I see BTU as a corporate altcoin
president, investor
paid dev for closed source updates
like they said BU = paypal 2.0
Listen, it doesn't matter. The debate is not about BU, it is about bigger blocks. We need bigger blocks now. If you don't like BU, that's fine. Just support whichever wallet implementation has enabled bigger blocks. |
|
|
|
This is a major release. CryptoGraffiti now renders ANSI colours properly, see the screenshot below. CHANGES in v0.90 since v0.85:- ANSI Colours are now properly decoded and displayed
- OP_RETURN decoding support
- New message box styling
- Whole page is now served as a single minified monolithic html
- Loading texts gradually appear while the page is loading its resources
- Most page elements are now properly resized in accordance to the font size of the browser
- Page header height is now dynamic and does not rely on CSS media queries
- Buttons are now displayed uniformly across all browsers
- Payment area now displays the QR code of the Message Encoder's BTC address
- Users are now actively notified if the message encoder is not responding
 |
|
|
|
|
I am building a totally single-threaded C++ wallet manager that uses C signals. However, I also need to use Bitcoin RPCs in a non-blocking way, so I devised a clever way to utilize popen with ampersand & in the end of the system command where I call curl to do the RPC for me. The popen command eventually pipes the RPC response back to my wallet manager over netcat / TCP. The problem is that signrawtransaction sometimes can take an argument that is longer than ARG_MAX in Linux (maximum command line length). So popen will fail if I provide the raw transaction hex as an argument to popen. What are my options to overcome this limitation and still have my wallet manager single-threaded and signal safe?
I investigated the use of anonymous pipes so that before popen (write mode) I'd call fork and send the raw transaction hex to popen over its stdin instead of command line. However, conceptually fork would make my program multi-threaded so I don't like it. Also, the child process would inhert the signal handlers and would probably receive SIGALRM really often because my main process gets it 8 times per second. So, what are my options here? I could use connect and craft my own HTTP request for Bitcoin Wallet's RPC but I don't want to block my program until connect finishes and I don't want to implement HTTP protocol related stuff in my code.
The only option that I find the most suitable in my situation is to use named pipes (makefifo). I create a named pipe in the tmp folder with a random name, then call popen which takes its stdin from that named pipe, then I write the raw transaction hex into the pipe and continue with my main program immediately. The popen command has an ampersand & in the end so it does not make my main program hang. Is there anything badly wrong with such architectural choices? Is there anything that I might not have thought of? Perhaps named pipes are somehow discouraged or slow? What chmod should I use on the named pipe for maximum privacy? I still have to open the named pipe in my main program and the open system call itself could block. Is it still faster than using connect? My main concern here is slowing down the main process due to blocking system calls. The curl requests can be slow, I don't care about those, but the main process should use as little potentially blocking system calls as possible.
Thank you in advance, whoever you are who can give constructive feedback to my problem/solution.
|
|
|
|
Afaik, there is nothing in BU's protocol which insures that the block size can only increase "a little". Your third quoted sentence above is not even wrong. As a full node operator I have a power to reject blocks larger than my threshold of confidence. Core does not even provide the users with such an option which is incredibly selfish of them. It puzzles me how you are quite reasonable with constructing the arguments backing up your own philosophy but when trying to undermine the opposing philosophy you suddenly lose the way of reason and give in to emotion. As a market equilibrium expert you should know that miners are definitely not going to increase block size to infinity. Even if they wanted to it would be physically impossible due to orphan rate. Well those who make the wrong decisions end up bankrupt. So let's hope we all get a chance to decide whether to hold BTU or BTC. Because I understand BTU is incompetent and its supporters don't understand blockchain technology.
That's right. You cast your vote and I'm casting mine. But those who have so far been neutral in this debate will most likely choose the side that does not censor opposing arguments (which by the way is a big red sign of weakness). |
|
|
|
But Bu is just an altcoin. does it mean that bitcoin will become just like any other altcoin?
BU is not an altcoin, it is a proposal to solve the Bitcoin's block size issue. Bitcoin's consensus is working as originally intended by Satoshi Nakamoto (miners vote with their hashing power). Right now miners increasingly prefer Bitcoin Unlimited. BU does not actually mean unlimited block size. It means unlimited potential. Doing nothing hurts Bitcoin more than increasing the block size a little. @iamnotblack Long text = shit text. If you can't deliver your arguments reasonably briefly then your arguments might not be worth reading. Conventional rhetoric does not work in the Internet whether you like it or not. And believe me, you wouldn't want to raise your annoying voice in the jungle either. Those who need long paragraphs to explain a simple idea are basically executing a Denial of Service attack on the readers. My response to your DOS is simply to ignore it. You have this unreasonable paranoia of potentially unlimited blocks and then you have this wild fantasy of how you imagine market equilibrium playing out. You refer to "smart people" and you think you have nailed it. Don't make me laugh. If you're so smart then why aren't you rich yet? Because everyone else is too stupid to believe your ideas and see the light? Let me tell you something about online debates. You can't win them. So if you are writing long texts and I am refusing to read them then you are the jackass DOSing yourself while writing stuff that no one bothers to read. At the end of the day I believe even more in the Bitcoin Unlimited project and you will probably believe even more in this new altcoin called SegWitCoin that innovates by introducing Proof-of-BlockStream where consensus is dictated by the best interests of the BlockStream company. |
|
|
|
|
@iamnotback
you write a lot of text and you fail to deliver your point. please go rant somewhere else or learn to explain your thoughts more briefly. yes, there are a lot of cool words in the English language and I'm sure you'd like to use all of them but if you want people to bother to read your texts then keep it short. I believe this is not a poetry subforum. I've seen your kind in the university, you have a lot to learn how communication works on the Internet. I'll bet you're not good with girls either.
I guess your fallacy lies in the fact that you assume everyone else is as egoistic as you are. You're probably also an atheist. Well, here's a big shocker for you --- people are not as egoistic as you think they are. Miners care about the future of Bitcoin and since they have invested a lot in mining equipment they will most likely defend their investment. If miners vote for bigger blocks then so be it, that's Nakamoto consensus and it's the Bitcoin I signed up for in 2011. If you don't like it GTFO and start your own shitcoin with a different ruleset.
|
|
|
|
if you mean infiltrated by a corporate takeover called Blockstream, i've been saying that for 2 years.
Yes, that's exactly what I mean. People, please start using a Bitcoin Classic or Unlimited node instead of Bitcoin-core because by doing this you are voting against the activation of SegWit even if you're not a miner. SegWit is the single most dangerous proposal to the Bitcoin network we have ever had. |
|
|
|
The bug in Bitcoin Unlimited is fixed already, updated all 3 of my full nodes and actually none were even attacked. Bitcoin Unlimited blocks continue to rule over this ugly thing SegWitCoin. Pic related, SegWitCoin sucks. And only dumbasses like Dafar (more like Jaffar) support it because they clearly don't understand that SegWit = Trojan Horse which will not serve the Bitcoin community but instead serves the interests of global bankers who want to gain control over the Bitcoin Network. They are such sore losers, just read what BlockStream's president has to say in the article linked below.  I remember bugs like this happening to core wallet back in the day when they still made effort to enhance the Bitcoin protocol. Now the core team is just stagnating. And they are so egoistic they are unable to accept defeat and unable to see that the Bitcoin network has rejected SegWit. It will never activate, they know it and they are not making any other proposal. Many of SegWit supporters blindly think it is for the good of the community but in reality it will just fill the pockets of BlockStream CEO and other corporate gangsters. Also it will centralize Bitcoin around the Lightning Network hubs. An Undercover Interview with Adam Back, Blockstream’s President |
|
|
|
So instead of just labelling her as "expert", you should acknowledge that she is far from impartial. Then, ideally, people can do their own research, make up their own minds.
Just because someone on the Internet labels someone else as expert does not mean you should not do your own research. I personally think that what she says is highly plausible in this context. Does not take a genius to see that SegWit is funded by bankers and without it blockstream will probably go bankrupt. |
|
|
|
Some people who make mistakes when trading just cannot believe that it was their fault - so they invent some hidden evil forces to blame them.
not sure who you are referring to. but anyway, BTC is increasing in value like a true king while Bitcoin Unlimited adoption is also increasing and segwitcoin is losing the battle like a bitch. pic related  |
|
|
|
S bitcoin could split, fork whatever the term is?
It's not a fork/split when 90+ % of the miners choose it. Then it's a peaceful protocol upgrade. On the other hand, SegWitCoin lunatics might want to pull something off when they see themselves losing the battle. They are known to be sore losers and that's the kind of stuff desperate people do. I was assuming they would go separate ways like ethereum That's what they want you to believe. That's the boogeyman SegWitCoin mafia uses to scare the public. The reason Ethereum forked so bad was because it is not a truly decentralized token system, it is centrally controlled and planned. Ethereum was corrupt from the very beginning but Bitcoin was not. That's why you can't use Ethereum's failure as an analogy to SegWit / BU debate. |
|
|
|
|
Bitcoin Unlimited will execute a proper and successful protocol upgrade with super consensus. TX fees will go down dramatically, Bitcoin scales to meet the demand. Value goes up a lot because value actually went down when the block size debate started. When it ends the value will recover.
|
|
|
|
S bitcoin could split, fork whatever the term is?
It's not a fork/split when 90+ % of the miners choose it. Then it's a peaceful protocol upgrade. On the other hand, SegWitCoin lunatics might want to pull something off when they see themselves losing the battle. They are known to be sore losers and that's the kind of stuff desperate people do. |
|
|
|
And the 'good guys' are who?
The ones who want Bitcoin to scale, remain decentalized and free as in freedom. |
|
|
|
But getting to the real crux here, I see both sides of the blocksize argument. But still it should be made clear, isn't this Amanda from DASH? If so, she has her own conflict of interest in damning Bitcoin.
Yes she is a DASH pumper. But I guess erryone in the crypto business has a preference. So I don't think what she says is absolutely wrong just because she hypes DASH. Anyway,
Her argument (after watching more) is that Blockstream is paying the devs and they are funded by outside interests. But there are over 100 core devs, right? So unless there is a massive case of groupthink, the code should speak for itself as anyone with the skill can review it. It would follow that if lead core devs were being 'turned', a migration away from Core would ensue.
I sympathize with Big Blockers. For those running a business and conducting multiple transactions frequently, rising fees are a big negative. The LN solution would enable scaling but pay fees to certain groups which can be interpreted as not being in line with Satoshi's vision.
Maybe that is right. Or maybe as the system matures it morphs into a more comp sci coder led tool than anarcho-cap one and this is Ver losing relevance as the ecosystem outgrows the need for an evangelist? I don't know.
I'm secretly hoping that the Core devs are just milking BlockStream dry of funds and that they never intended SegWit to be actually activated. They deliberately made it as tough to get activated as possible so that the good guys would eventually win, and they'd get paid while buying cheap BTC with their massive salaries paid by the Blockstream banksters. Yeah, that would be great. |
|
|
|
|
Show Posts
