Re: sending to a large number of output addresses
Den måndag 17 oktober 2016 kl. 12:47:12 UTC+2 skrev Wei Hsu: > > True, sending one by one will cost more in fees. More importantly for me, > it will take a lot more time to send them one by one. > > Limiting the number of outputs might still result in a transaction that > exceeds the maximum size, since we don't know how many inputs the > transaction needs. That makes it difficult to partition the recipient > addresses ahead of time. For my application, it would be helpful to create > all the transactions first and then broadcast them in a separate step - > wondering if that's possible to do with BitcoinJ in this case. > > Yes, you can control inputs with not too much work. You could use Wallet.calculateAllSpendCandidates and analyze your spendable outputs, decide on a set and add up an amount that's max for your tx, then write your CoinSelector to select exatly those as inputs you added up to the amount with. > On Mon, Oct 17, 2016 at 3:26 AM Jarl Fransson > wrote: > >> I think it is bad to send them one by one. Also, in total that will >> require more resources and cost more in fees. You should probably find a >> reasonable limit for the number of outputs and create a few larger >> transactions if your number of addresses exceed that limit. >> >> Den fredag 14 oktober 2016 kl. 22:52:44 UTC+2 skrev Wei Hsu: >>> >>> Given a large number of output addresses, what's the best way to send a >>> payment to each one? Assuming the wallet balance is sufficient. >>> >>> If I send the payments one by one in quick succession, I might get >>> an InsufficientMoneyException if some of the funds are tied up in change. >>> >>> I've also tried combining it all into one transaction, but that could >>> result in a transaction that exceeds the maximum transaction size if a lot >>> of inputs are required, or a lot of output addresses are specified. >>> >>> I'd appreciate any ideas on how to approach this- thanks in advance! >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "bitcoinj" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/bitcoinj/e_hiH9Dqhs0/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> bitcoinj+u...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: sending to a large number of output addresses
True, sending one by one will cost more in fees. More importantly for me, it will take a lot more time to send them one by one. Limiting the number of outputs might still result in a transaction that exceeds the maximum size, since we don't know how many inputs the transaction needs. That makes it difficult to partition the recipient addresses ahead of time. For my application, it would be helpful to create all the transactions first and then broadcast them in a separate step - wondering if that's possible to do with BitcoinJ in this case. On Mon, Oct 17, 2016 at 3:26 AM Jarl Fransson wrote: > I think it is bad to send them one by one. Also, in total that will > require more resources and cost more in fees. You should probably find a > reasonable limit for the number of outputs and create a few larger > transactions if your number of addresses exceed that limit. > > Den fredag 14 oktober 2016 kl. 22:52:44 UTC+2 skrev Wei Hsu: > > Given a large number of output addresses, what's the best way to send a > payment to each one? Assuming the wallet balance is sufficient. > > If I send the payments one by one in quick succession, I might get > an InsufficientMoneyException if some of the funds are tied up in change. > > I've also tried combining it all into one transaction, but that could > result in a transaction that exceeds the maximum transaction size if a lot > of inputs are required, or a lot of output addresses are specified. > > I'd appreciate any ideas on how to approach this- thanks in advance! > > -- > You received this message because you are subscribed to a topic in the > Google Groups "bitcoinj" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/bitcoinj/e_hiH9Dqhs0/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > bitcoinj+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: sending to a large number of output addresses
I think it is bad to send them one by one. Also, in total that will require more resources and cost more in fees. You should probably find a reasonable limit for the number of outputs and create a few larger transactions if your number of addresses exceed that limit. Den fredag 14 oktober 2016 kl. 22:52:44 UTC+2 skrev Wei Hsu: > > Given a large number of output addresses, what's the best way to send a > payment to each one? Assuming the wallet balance is sufficient. > > If I send the payments one by one in quick succession, I might get > an InsufficientMoneyException if some of the funds are tied up in change. > > I've also tried combining it all into one transaction, but that could > result in a transaction that exceeds the maximum transaction size if a lot > of inputs are required, or a lot of output addresses are specified. > > I'd appreciate any ideas on how to approach this- thanks in advance! > -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
