Topic: [CONFIRMED] Why not confirming? Over 0.01 under 10k size, even includes a fee... (Read 1918 times)

Thanks for the tips.

And yea thats generally what I aim for, just under 10k and just over 0.01 - or greater if I have the unpaid BitHits/Affiliates to send to and I've got room left in my tx.

I think the largest tx I sent that was still under 10k was around 360 or so outputs.

And the 1st parameter of SendMany does ask for an address label. And ... It usually does take the coins from that address first I've found (assuming they are there to send). I've sent dozens of transactions with SendMany and it has worked in that fashion.

As far as peers not relaying, I am considering setting up a mining pool on one of my domains for this very purpose, probably using P2Pool to confirm 0fee transactions of any size or input.

I didn't think SendMany lets you choose addresses.  I thought it only let you choose which "account" to send from.  "Accounts" in Bitcoin-Qt do not work the way many people assume they work.  When people make assumptions about how accounts work and then attempt to use accounts based on those assumptions, they generally end up with unexpected and unintended behavior from the wallet.


I haven't tried to create any really big transactions yet, so I don't know if the API limits the size like that.  If you want or need to create transactions bigger than 16,383 bytes, then you'll have to see if the API would allow it.  I suspect it will.


If you are already using a script to generate the transaction, you might want to look into having the script communicate directly with the API so you don't have to paste it into the Debug Console.


When creating a transaction with createrawtransaction, be aware that if you don't pay a fee of at least 0.0005 BTC per kilobyte for any transaction that triggers a fee requirement (larger than 10 kilobytes, any output less than 0.01 BTC, priority calculation result is less than 57,600,000) , then you are likely to run into issues with peers relaying it.

Also, when using createrawtransaction, be VERY CAREFUL to make sure you send the change from the transaction back to an address you control.  This is a step that has been accidentally forgotten by even experienced and knowedgeable bitcoin developers and can result in paying all the change from the transaction to a miner as fees.  It can be an expensive mistake to make.

SendMany does allow you to control the address thou. I generally empty the address each time and then load it with more then enough to send whatever transaction I'm going to send. In the case of this transaction thou. The tx fee put it well over the amount i had allocated for that tx and even a few more.

I've also noticed the debug console humorously limits you to 32,767 characters.

I'm currently using some scripting and a source list of addresses to generate my SendMany request. I could probably write a similar script to do a SendRaw once I get all the particulars down. Which I would probably do in the same fashion, generate the request and use the DebugConsole.

Eventually I'll get a VPS with a bitcoind instance on it.

The most addresses I've sent to at one time was about 2600 That tx was like 100kb I figured If im going to pay an outrageous fee... I'm going to make the tx as big as possible.

I'm familiar with the tool.  I've never used it because it has never suited my needs.  I prefer createrawtransaction.  SendMany doesn't allow you control over the specific inputs you will be using for your transaction, and it doesn't allow you any control over your fee.

Note that with both SendMany and createrawtransaction, you don't have to use the Console.  You can create a program/script that will communicate with the wallet directly.

Either way, one of the nice things about createrawtransaction is that you can review your transaction before you send it.  When createrawtransaction presents you with the raw transaction, it hasn't yet sent it to the network.  You have to use sendrawtransaction for that.  This means that you can run decoderawtransaction both before and after you run signrawtransaction to review your transaction and make sure that it is doing exactly what you intend.

The fact that is works sometimes, isn't a guarantee that it will work every time.  As you have already seen, and already know, SendMany hasn't "worked perfectly" for your needs.  If it had, you wouldn't be upset.  SendMany can be a useful tool, but there are other tools to consider, and clearly SendMany is the wrong tool for your needs.


But Sendany doesn't allow you to "make sure you're hitting the right inputs and size".


Use something like createrawtransaction and you'll have much more control over the inputs, outputs and fees.



While I've used createrawtransaction quite a bit to have more control over the specific inputs in my transactions, I haven't used it for very large transactions yet.  I'm not aware of any limitation on number of outputs imposed by createrawtransaction, but I supposed you'd have to try it to be sure.  It would be a good idea to try it on testnet before playing around with actual bitcoins.

Thanks aaaxn

I actually probably have above average knowledge of bitcoin, being that I'm a developer (not a BitCoin developer, but a developer nonetheless) and I run not 1 but 2 *coin Faucets. Hell you might even say I'm advanced.

Just imagine what a regular run of the mill user that just downloaded it and has never compiled anything in their life must think when something like this happens.

An extremely easy fix for this ... Would be to add SendMany support to the GUI without having to resort to the debug console and even if we are using the debug console at the very least give us an option to accept or decline the transaction based on the fee.

@Danny

I dont know if you've ever used the Debug Console or SendMany. You just put in your transaction after tediously building it. Enter it in console and poof, Your presented with a tx id thats already propagating in the blockchain, I dont even know what my tx fee will be until its on blockexplorer or i check tx details from the already confirming transaction!

Great attitude. Have problem with bitcoin? It can't be poor bitcoin design, you must just be too stupid for this. It's perfectly normal that user need to have master knowledge of bitcoin to send payments with reasonable cost.

.. But SendMany has worked perfectly with reasonable fees for large transactions with many many outputs for me. That why I use it. I just need to make sure I'm hitting the right inputs and size. Which i loosely calculate before hand. Its only the fee that can fuck things up by screwing with my input.

I have been meaning to look into Raw Transactions, I just havent yet. Been trying other clients, reading up on various wallet API's and seeing if I could implement that instead. The 'ideal' number of output addresses is around 200 - 350 - Not sure how feasible it would be to create such a transaction with raw.

Then you haven't figured out a very good way yet.  Perhaps look into using createrawtransaction, where you'll have complete control over the inputs used and the fees paid.


Then clearly SendMany is the wrong tool for what you are attempting to accomplish.


There is no "Official" client, but if you can find a client other than the reference client released by the Bitcoin Foundation that will allow you to create usable transactions, then go for it.


The current fees exist to prevent a DDoS attack on the bitcoin network.  If a significant number of people start running a modified client that relays "low priority" transactions without a fee, I would expect them to eventually run into significant issues with disruptive participants attacking their network.

This isnt 'my business' This is my hobby. My business...Is what I get up and do full time. i cant pay my rent in bitcoins, I cant buy food in bitcoins so no, Bitcoins is not 'my business'

And I have in fact figured out a way to send bitcoins with little to NO fucking fee. Except it doesnt work everytime. Based on the rules of the protocol, If that fee had been a reasonable value. It would have sent just fine without the 200% fee applied. But the whole reason there was a 200% fee was because of the fee itself. With a 'normal' fee - the size of the tx would have been maybe 1/4 of what it was. And the fee would have been a lot closer to 0.01 or 0.005. Much more reasonable.

The main issue is that when I use SendMany I do not get to review my tx fee before it is deducted and the transaction is added to the blockchain. Its like a gamble with every send.

But I've successfully sent several tx in a row without a completely disproportionate tx fee, Every so often thou. The client doenst exactly behave in a favorable fashion and fucks me.

I'm more then likely going to stop using the Official client and use a client that either affords me more control over the transaction or just start sending coins with 0fee if someone ever compiles the client from my sig. And I hope to hell everyone starts using it (Who wouldnt want to send their coins for free? Its not like coins arent still being seeded out at regular intervals with blocks solved ... why the fuck do we even need fees right now.)

Sounds like a poorly designed business model combined with a failure to properly build transactions.

There isn't any reason that a properly run business should be paying 0.05333333 BTC in fees per transaction.

If you can't figure out a way to run your business with lower fees, then it doesn't surprise me that your business is about to die.

BitCoin still broken by fees. BitHits.info payouts suspended until further notice

see https://bitcointalksearch.org/topic/important-notice-regarding-wwwbithitsinfo-payouts-209749

This may very well be the death of BitCoin for me. I've probably paid close to $200 in tx fees just to send bitcoins. (Across 30 payouts to users of BitHits.info)

Hopefully a legitimate AltCoin can emerge that fixes this huge issues. If I knew C++ well enough I would do it myself! Believe me.

I mean seriously, What business is going to spend $200 for 30 transactions? How is this supposed to get adopted.

Correction.

A few seconds to electronically send $6.90, and less than 2 days for the transaction to become irreversible.  I can't think of many other methods of electronically sending value that are that fast.  Any that I can think of that are fast require a much higher transaction fee than $0.015.

bait

+2,454 minutes to send $6.90. Not bad. 

UPDATE; Transaction has confirmed 16 confirms

i think there is a misunderstanding here: you are not the mainstream. bitcoin will be become mainstream just fine without supporting those irrelevant transactions you hold so dear. it's not a flaw to not support them, it's a deliberate design choice. just like not going for peter todds two-transactions-per-day-coin and eventually increasing the block size instead will be a deliberate design choice too. i have no trouble with radical opinions. but people with radical opinions thinking their niche problems matter to everyone are getting really exhausting to deal with here.

please just deal with the fact that the vast majority doesnt want what you want and fork if you need 0,00001$ transactions.

1.6kb is large ? :S Damn. Its a shame BitCoin still suffers all these tx flaws. Its because of shit like that that BitCoin will never be supported in the mainstream. Its too easy to 'lose coins in limbo' due to the flawed tx fee/priority system.

I really wish someone would come up with an AltCoin to address these glaring flaws so BitCoin could finally evolve into something everyone can use...for anything...large, small, fees, no fees. (That is after all what BitCoin was supposed to be? Right!?)

BitCoin was supposed to be divisible up to 8 places ? (Or was it far more then that?) Clearly that's been patched out since the original implementation. Satoshi would be proud ... :x

Your transaction is large and your inputs are young and small, so the transaction has very low priority, so it's unlikely to get selected for the free part of the block. And your fee/kB is also tiny, so it won't get selected based on that either.

0.8.2 isnt even released yet!? Why would miners be using those rules? Most miners and clients are probably still on 0.7.x or 0.8.0 or 0.8.1

Definitely not 0.8.2