Show Posts
|
Pages: « 1 [2] 3 »
|
well it wouldnt be a new thing to bitcoin if it wasnt getting a confirmation for a hour and a half, block times are fluctuating wildly there are sometimes even near instant blocks
to be honest i never worry about it though sometimes it makes me mad if i make a transaction to the website and it requires confirmations that might take so long to happen
I'm not claiming this is either new or surprising. I'm just saying there's a whole bunch of problem it creates when you operate a bitcoin based business. Maybe the lightning network will somehow solve the problem, but the base bitcoin network is a PITA to work with.
|
|
|
The whole thread should be deleted. Block confirmation time is working as designed. Use the search function and you'll find hundreds of threads saying the same thing you said. This whole thread is a waste of space.
If there's hundreds of threads on the same topic, it sounds to me like there's something unsolved and worth debating. Or has this forum become so polarized that open discussion disagreeing with local dogma is no longer welcome ?
|
|
|
Uh Looks like four of my posts in this thread that were basically stating actual facts verifiable by any and all were deleted by a mod ?? What's going on here ? Is reality somehow no agreeing with the bitcointalk orthodoxy ? That's quite amazing.
|
|
|
And still 10k+ unconfirmed. cleaning the backlog will be a while.
I dont know where you get your numbers, but there are way more unconfirmed TX than just 10k. Note the large drops on the 30d graph are system reboots, not backlocks cleaned up. I was getting my numbers from here: https://blockchain.info/unconfirmed-transactionsThey might not be taking everything in the mempool into account idk.
|
|
|
Whichever side of the block size debate you may be, this particular bitcoin headache (time between blocks) is still imho a problem. And it never gets debated, while ETH, which IIRC has a shorter time between blocks is busy stealing the show You were a bit unlucky there. On the other hand this is transaction i made today ( https://blockchain.info/tx/991b67bc5f7772b8582150b465c654a09c06e42e26f03b801eb79b8d97cf915f) it was confirmed as soon as i made it literealy it took just like 1 minute to first confirmation :] Well that's the thing, when it comes to how fast a transaction confirms luck should not be part of the equation, at least not on a timescale of hours (seconds maybe ok). Bad for business, and limits what can be done. How fast a transaction confirms should be a purely auction based, and given enough fees applied to a tx, it should confirm within a second.
|
|
|
Nice, except that my the txs I'm waiting for are still in flight, in spite of spiffy fees ! Care to share your Tx hash? Why, not really But rest assured fees aplenty were paid. It now has gone through.
|
|
|
And still 10k+ unconfirmed. cleaning the backlog will be a while.
|
|
|
1h30 mark is passed now:
|
|
|
Whichever side of the block size debate you may be, this particular bitcoin headache (time between blocks) is still imho a problem. And it never gets debated, while ETH, which IIRC has a shorter time between blocks is busy stealing the show
|
|
|
Dear BitBet users,
We are currently experiencing a DDOS attack very similar to the one our colleagues at Betcoin.ag were subjected to a couple of days ago :
And we're back !
|
|
|
We are being blackmailed by a DDos attacker. We have no intention of agreeing to his demands and are working on a mitigation with our hosting provider, the site should be back online within the next couple of hours. Please see this thread for details: https://bitcointalk.org/index.php?topic=1465796.msg15012021#msg15012021Thank you for your patience. The BitBet admin team
|
|
|
Dear BitBet users, We are currently experiencing a DDOS attack very similar to the one our colleagues at Betcoin.ag were subjected to a couple of days ago : https://bitcointalk.org/index.php?topic=386266.4420Below is a cut and paste of the extortion request we received. We have no intention to comply to their demands and we are working with our hosting provider on a technical solution. The Website will unfortunately be down for a while, but rest assured that all funds are secured (the wallet is not on the site), and so is the site database which is mirrored continuously to another machine. As our email server is co-hosted with the web site, please communicate with us on this thread. WE HAVE YOUR SITE DOWN LETS TALK
Hello Support,
We are a team of highly skilled independent security consultants. One of your competitors hired us to take your site offline for an entire month (which we have the resources to do but don't like the contact and might be able to work together instead) and I must say that we have seen ALOT of miss-configured sites with security issues but it took our DB expert less then 30 minutes to dump your sql database without setting off your IDS system.
We want to disclose some of the flaws we found with you and have already put a significant amount of time in researching, exploiting and then documenting the vulnerabilities we found. Unfortunately, most site owners don't give a shit and would rather wait for more malicious hackers to come along. We are going to stop that from happening.
We are taking your site offline until we here from you. Our initial consultation will cost 1 BTC. That price will go up half a btc for every 12 hours we have to keep your site offline. I want to personally assure you that we have the power to keep your site down for an indefinite amount of time. We are the ones who took down xbox live all week (testing ONE of our new servers). In addition to lletting your site up and giving you a report of what we found and how to fix it we will also let you know the ONLY way to stop a DDos attack the size we are capable of launching. We will also add you to a blacklist so no one else fucks with you.
The BTC can be sent to the following address : 14U5q4AJhKiefui7f2d3ZmSq4FWkLfnDjK
I know that you are going to try to mitigate but in the end that is only going to cost you a lot more money. You make enough from betting and advertising alone that just an hour of downtime wont justify the cost. Our team also understands that you will try to mitigate but nothing will stop the attack except my command. Your hosting provider will not be able to help, the authorities wont be able to help you, your firewall is easily bypassed and any ddos service you try to bring in we can bring down (we have done this for a long time). believe it or not we are not the masked assholes stealing credit card numbers. Most of us have families and can't find legitimate jobs in our fields right now and have families to feed.
You have active bets and every minute you spend trying to mitigate your losing more then our consultation fee. We took down xbox live for a week with one server, believe me no one can stop our attacks. Lets work together!
Regards,
GETDD0sed
|
|
|
Yeah well, that's the part I'm not getting at all The hash of the transaction is AFAIK the hash of all data contained in the transaction, including the input sigs. It's like a snail biting its own tail. Or are the sigs somehow signing a version of the TX with the sigs omitted or left blank? I must confessed to being a bit confused. The hash is a hash of the transaction with some modifications. Those modifications are: the input scripts areblanked out (replaced with 0x00), the input that is currently being signed is given an input script of the output script the transaction refers to, and the sighash code is appended to the end. Then that is hashed and that hash is signed. The signature produced is then placed into its corresponding input's scriptsig. This link might help: https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-txSuper, now I get it. Thanks for taking the time to explain !
|
|
|
The signature is the signature of the hash of the transaction. The hash is computed on the fly and if the signature does not validate to the specified public key with the hash as the input, then the signature, and thus transaction, is invalid.
Yeah well, that's the part I'm not getting at all The hash of the transaction is AFAIK the hash of all data contained in the transaction, including the input sigs. It's like a snail biting its own tail. Or are the sigs somehow signing a version of the TX with the sigs omitted or left blank? I must confessed to being a bit confused. Cool. And will the satoshi client be able to do this (as in : spend from an unconfirmed TX with large fees) ?
It is a little complicated. I think that (I'm not quite sure) if you enable coin control you should be able to select unconfirmed inputs to spend from. Otherwise you will have to use the RPC console to craft a transaction by hand with the raw transaction RPCs and broadcast that. [/quote] Yeah, was expecting that coin control was the answer. I need to go experiment with that on testnet. Thanks !
|
|
|
What you are proposing is entirely impossible. It is not possible to "dissect and reassemble" an already broadcasted transaction without having the private keys that spend the inputs. You cannot add inputs or outputs to the transaction because the signatures for each input ensure that the transaction has not been modified in any way.
OK, didn't realize the signature of each input was somehow bound to the TX itself. I wonder how that works. Gotta read up on this. Otherwise anyone would be able to steal other people's Bitcoin.
Indeed. Good point. The solution to your problem is called Child Pays For Parent (CPFP).
Cool. And will the satoshi client be able to do this (as in : spend from an unconfirmed TX with large fees) ? If so, I guess that solves my problem. Thanks for the explanation.
|
|
|
Hello,
I have a question that I think is becoming more and more relevant in these days of systematically full blocks and where getting transactions confirmed is increasingly becoming a total crapshoot.
Say someone sends me bitcoins. I discover this because coins are sent to an addie I control and therefore my wallet latches on to it and displays it in my transaction ledger.
However, upon close examination of the transaction, it becomes clear that the cheapskate who sent it included way too little fees and the TX will take ages to confirm, if ever.
At that point, if it's essential enough for me to get the funds that were sent, I would not mind actually paying the fees *myself* to lubricate the confirmation of this TX.
Three questions:
- is this theoretically even possible ? Can I somehow dissect the already broadcasted TX to reassemble it into a larger one with addt'l inputs (say an input from an addie *I* control) so as to pay higher fees ? And once that is done, broadcast this newly constructed TX, which would hopefully get prioritized before the old one and make it a double spend.
- if possible, is there a tool / wallet out there that would let me do this, or, barring that, is there a way to pull it off via the satoshi client RPC interface.
- also, if possible, in the scenario where: - old TX is stuck - I construct new, higher prio version - I broadcast new version - old TX gets included in a block, making the new one a double spend then what happens to the "extra" input I added ? Can that signed input somehow be reclaimed by someone ?
Any wisdom on the topic is welcome
|
|
|
I really doubt if the 800 dollar can be reached but maybe with the halving that is coming its possible this year. I hope it will happen but this is of course still the question.
don't make yourself waiting for something that won't happen this year. it's too much just to happen in such a short time. i think if we reach $500 and manage to stay above that price level for the rest of the year, then that's a great achievement. more can we not ask for. And now <drumroll> you can put your money where your mouth is: https://bitbet.us/bet/1272/bitcoin-to-top-1000-usd-before-january-2017/
|
|
|
|