Show Posts
|
Pages: [1] 2 3 4 5 6 7 »
|
Does anyone know if bitni.com is trustworthy? It says on the page "Need Help? Expert 24/7 support is ready to assist you." But I haven't received an answer to my question.
|
|
|
I initiated an ID verification on Bittrex. To protect myself against possible future identity theft (when Bittrex gets hacked), I wrote Bittrex.com and the current date on a transparent plastic strip and I attached the strip to my passport in a way that it does not cover anything important. I got the basic idea from here: https://www.reddit.com/r/LifeProTips/comments/2icgq9/lpt_if_you_really_need_to_upload_an_id_scan/?st=jq0v3ovg&sh=73db4524This way, if Bittrex.com gets hacked and customer ID photos leak into the darknet, criminals would have hard time using the photo of my passport to conduct KYC at some other service provider. Since the label is physically attached to the passport before taking the photo, I am not violating the terms which say that photo manipulation is forbidden. On the one hand, I prove to Bittrex that I am really the person that I claim to be. On the other hand, if Bittrex goes rogue or gets hacked, my identity will still be safe. Great! So what's the problem? The problem is that Bittrex insists on me removing this label even though I am not violating any rules. I have not used any photo editing tools to manipulate the photo in any way. The image is scanned in high detail, allowing experts to easily verify that both the label and the ID document are authentic. Why on earth does Bittrex insist on me removing that label then? Unless, they are illegally selling the KYC photos of their customers to 3rd parties. And of course, a photo like mine would not make them any money. I have used this same exact method to verify my account on other exchanges and there has been no problem with it. EDIT 26-12-2018: They asked me to send them another photo (me holding a paper with text bittrex, the date and also holding my government issued ID). I was able to send that photo over e-mail, which means they finally approached my case manually. After that they enabled my account (YAY!). I immediately bought BSV for all the funds I had there and withdrew them all. Never looking back though.
|
|
|
I have implemented a program that monitors all mempool entrants and checks whether any of them spends outputs that have already been spent by some other unconfirmed TX. For some reason, my program never detects any double spends this way. Does anyone know why? I'd guess it is because the BitcoinCore full node implementation does not allow double spends in the mempool, it's as if they were invisible. However, blockchain.info seems to detect them immediately and reliably so I know it has to be possible. Any tips and hints would be extremely welcome. Thanks!
|
|
|
I don't know what just happened, but when I opened this tab I got this: This is pretty plausible actually if we get this dumb SegWit proposal out of the way and Bitcoin starts to scale on chain using FlexTrans.
|
|
|
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.
|
|
|
Well this sucks, I knew it. https://www.youtube.com/watch?v=rp6DaMiORBUBut at least it proves SegWit is evil and should be rejected ASAP if we want BTC to keep ruling them all. BTW, ETH, DASH and monero are all PnD vapourware/shitcoins. Only buy/sell it to profit on idiots who actually believe in those. The true innovation is ByteBall but it is probably going to take a while when it becomes popular mainly because there is no ICO. No ICO = no ICO funds to be spent on paid ads and marketing (point @ ETH and other shit). Ethereum is no threat because it's not even a currency and their branding is just awful. A taxidriver would never buy ethereum. Dash got it semi-right by ditching "darkcoin" but it has no innovation so it will fade away as soon as the whales have unloaded their stash.
|
|
|
As of today SegWit is losing to Bitcoin Unlimited. We can actually get done with this block size debate. Please spread the word and install Bitcoin Unlimited full node instead of Core. This debate has been holding back the price for too long now. It's time for change. Let's make Bitcoin great again. Graph source: http://xtnodes.com/graphs.phpThe Bitcoin Unlimited (BU) project seeks to provide a voice to all stakeholders in the Bitcoin ecosystem.
Every node operator or miner can currently choose their own blocksize limit by modifying their client. Bitcoin Unlimited makes the process easier by providing a configurable option for the accepted and generated blocksize via a GUI menu. Bitcoin Unlimited further provides a user-configurable failsafe setting allowing you to accept a block larger than your maximum accepted blocksize if it reaches a certain number of blocks deep in the chain.
By moving the blocksize limit from the protocol layer to the transport layer, Bitcoin Unlimited removes the only point of central control in the Bitcoin economy - the blocksize limit - and returns it to the nodes and the miners. An emergent consensus will thus arise based on free-market economics as the nodes/miners converge on consensus focal points, creating in the process a living, breathing entity that responds to changing real-world conditions in a free and decentralised manner.
This approach is supported by the evidence accumulated over the past six years. The miners and node operators have until now been free to choose a soft limit which, as demand grew, has always been increased in a responsive and organic manner to meet the needs of the market. We expect miners to continue in this tested and proven free-market way by, for instance, coordinating to set a new generated blocksize limit of 2MB and reject any blocks larger than 2MB unless they reach 4 blocks deep in the longest chain. As demand increases, the limit can easily be increased to 3MB, 4MB, and so on, thus removing central control over the process of finding the equilibrium blocksize by allowing the free market to arrive at the correct choice in a decentralised fashion.
As a foundational principle, we assert that Bitcoin is and should be whatever its users define by the code they run, and the rules they vote for with their hash power.
|
|
|
This is a quick side-project of mine, mainly developed as a template/example for other developers who want to save custom messages on the block chain. The base functionality is derived from CryptoGraffiti.info. Source code: https://github.com/1Hyena/blockchanPossible use cases include censorship resistant commenting under any keyword. For example, let's say you have a blog but you want to enable censorship resistant commenting for your site. Then you would simply include BlockChan in an IFRAME sandbox below your blog with the following source: http://cryptograffiti.info/chan#myblog.com/blogpost123The iframe will display all the messages written under the "myblog.com/blogpost123" category (case sensitive). I will gladly explain the technical details when asked. Just let me know if you have any questions. Here are some screenshots:
|
|
|
1 Bitcoin currently costs 1182$ An ounce of gold is currently 1256$ Only 74$ to go. After that expect mainstream media news "Bitcoin is now more expensive than gold" The price will go vertically up after that, dwarfing the 2013 high.
|
|
|
2017 bubble has officially begun now. Prepare for mainstream news next week, FOMO, my prediction of 5000$ BTC is manifesting.
|
|
|
From time to time accidents happen. Yesterday something went internally wrong in the Bitcoin core based wallet when calculating TX fee so that dust was sent to my change address. I included a fee for the TX to be confirmed in 20 minutes but it hasn't confirmed for 18 hours now. It's because the change address contains dust so the TX does not confirm but is accepted by blockchain.info as a valid TX. This is not the first time when a TX does not get confirmed and it pisses me off a lot because it's technically really inconvenient to delete it from the wallet and make a "double spend" that fixes the issue. It would be much easier for me if there was a mining pool that offered a way for anyone to push non-standard TXs to the miner's mempool. I would have no problem paying extra bitcoins to the pool's address for the confirmation of the TX. Can anyone make such a service, point me to an existing one or just manually confirm my TXs for me? I think the TX fee is enough but I am willing to pay some extra. Here are the TXs that don't confirm: https://blockchain.info/tx/b550e8604c486b9ab00cb1cd09a6985de1a8c05554aec4f32aebb6df2a9c8bc3https://blockchain.info/tx/2e49019b1a8f8ab5e46892c60ff55e4f5f8291ec1b0ead9d5666af5548d43148
|
|
|
Seems like we are recovering quickly from this last shakeout of the weak hands. But why are those periodic with nearly exact time intervals? screen shot pc
|
|
|
YouTube reference here: The Case for $10,000 Gold If the world moves towards pure digital currency economy. What is the purpose of gold then? Something like bitcoin would be created or bitcoin could expand to become global. Nice to see the Illuminati actually mentioning Bitcoin in a rather bullish way.
|
|
|
I just came to this exciting idea what miners could do to help to solve the block size debate without losing their profits.
Every Bitcoin node can change the maximum block size the way they see fit. Just because it is a hard-coded constant does not mean we can't change it and still run the same old Bitcoin. So, one would download the Bitcoin-core and simply increase the maximum block size to whatever number. Before you start yelling the word "fork", read some more.
If I am not wrong, miners can mine blocks for multiple chains in parallel without losing anything. All a miner has to do is to track the forks of bitcoin and mine for all of them in parallel. For example if there exists 2 forks of Bitcoin, one with 1 MiB block size limit and the other one with 2 MiB block size limit, then the miner has to compile blocks for both of them.
The miner will compile one block that is not larger than 1 MiB and the other block that is not larger than 2 MiB, having 2 different blocks. Next, the miner will try to find a hash that satisfies the protocol constraints for any of those blocks. When mining the miner gets a lot of random SHA256 hashes. Should they run into a hash that satisfies the 1 MiB block, it's a success. The miner can get the reward and confirm it. Should they run into a hash that satisfies the 2 MiB block it's also a success. The miner does not care. They are still earning block rewards and transaction fees regardless of which chain is longer.
Finally, to save up some memory the miner has to forget a fork that gets too far behind the leading fork. For example if a particular fork is 4 blocks shorter than the leading chain then it is safe to forget it as a losing fork. This is what miners could already implement. It is a win-win situation.
By the way, does anyone know if SegWit serves any other purpose than just increasing the block capacity? It would be a shame to discard it after it's ready, so maybe we could have variable length blocks and segwit at the same time? Is it possible?
|
|
|
I have been in the Bitcoin business since 2011. I have obviously followed the block size debate and even tried to propose solutions myself. Today I was watching this video (Waves Weekly Crypto Roundup. Golem Project E06). In the very end it mentions that now a mining pool with 7% of hashing power supports Bitcoin Unlimited and thus Segwit will never get 95% of consensus. At first I thought it was really bad news for Bitcoin but then I started to investigate what the hell is Bitcoin Unlimited. Turns out that Bitcoin Unlimited is the ultimate free market solution to the block size debate. We already have child-pays-for-parent system implemented in Bitcoin. Now, removing the maximum block size limit is the next logical step. I am surprised that I didn't think of it myself a year ago. This is simply ingenious. A miner will not all of sudden start to produce 1 GiB blocks because it will be orphaned for sure. Free market is the natural protection against any attempts to abuse the absence of block size limit. The block size limit doesn't belong to the protocol layer as a strict number. Instead, it should be determined by the free market. Bitcoin Unlimited is the way to go. It's fully compatible with the philosophy of Satoshi Nakamoto. I support it because I support the free market. So, if Bitcoin Unlimited is so great, then why isn't everyone talking about it? I guess it's because several big boys have invested a lot of money into Segwit and other alternatives. Also, big miners with shitty internet speed do not like the idea of a theoretically unlimited block size. You know how this kind of situation is also called? Self-interest and corruption at the expense of the greater good. From this day I finally have a strong opinion on the block size debate and this is great. All I needed is to see that the removal of block size limit is a step in favour of the free market and that free market itself will eliminate all the problems that might rise from this. However, if you know that there is an option even better than Bitcoin Unlimited then please let me know in this thread as my decision about supporting Bitcoin Unlimited is not final.
|
|
|
I have been searching the Internet for quite some time now and haven't found an ultimate C or C++ function that validates Bitcoin addresses. Sure there is one here but it gives so many false answers it's unacceptable. I need the strictest possible most complete and fail-proof function written in either C or C++. It should correctly cope with addresses as short as 26 characters. Also, it should understand that addresses starting with 3 are also valid. If the address has not enough 1s or has too many 1s in the beginning then the function should return false. I believe I'm not the last developer out there searching for such a self-contained function so if you can help, please contribute to this topic.
|
|
|
The Cup with Handle is a bullish continuation pattern that marks a consolidation period followed by a breakout.
|
|
|
|