Topic: A thought occured today, are "bulk" transactions cheaper? (Read 1987 times)

Well that will change things a little bit. Probably most importantly, you need to understand that you cannot simply "add transactions together," all of the inputs in a transaction need to sign the entire transaction -- this means that if you have a transaction in which 7 users are sending funds, but only 5 of those users sign the transaction (assuming 1 user = 1 input), then you will not be able to send any of the transaction until the remaining two users sign the transaction, or alternatively you create a new transaction spending funds from the 5 cooperating users, that each of them sign. This will result in you having a tradeoff in that it is likely that many of your transactions will fail because users refuse to sign a particular transaction for one reason or another, and depending on how many users you have/how frequently you are creating transactions, this may lead to long delays in being able to even broadcast a transaction.

Additionally, if each user has their own address and own private keys, then I would presume that if a user does not spend an entire input, that they will also have their own change address, which would mitigate the savings that I described above.

Under my understanding of your setup, you would save about 40 bytes per transaction that you can eliminate, and you would have the tradeoff that there might be delays in broadcasting transactions.

One other thing to keep in mind is that having large transactions might result in you having to pay higher tx fees rates (on a per byte basis). For example, if your transaction is only 0.24 kB, then your transaction might be the cheapest transaction confirmed in a block if you are paying 0.0000012 BTC per byte because there are no 0.24 kB transactions that pay that high of a rate. However if your transaction is 150 kB, you might need to pay something closer to 0.0000018 BTC per byte because you will need to outbid many more transactions competing for that greater block space.

I believe Roger Ver has vested interest when he made that comment. He may have invested in Dash months before making it. I also see it as a spite on Bitcoin because there are not enough supporters on their Bitcoin Unlimited hard fork. Instead of creating the BU altcoin he is now supporting an altcoin.

Pope of nope. I can keep using the Bitcoin testnet for the moment as I have 10BTC on it, and mobile apps that I know work properly. The software is modular so changing coin on the back-end is easy.

I guess when I have a more substantial prototype system working trying to work on an inter-service blockchain for off-main transactions would be a possibility. Not going to look into that yet though, someone else may have sorted it by the time I am near a working system.

Is the testnet working yet? If not, you might want to look in the altcoin section to see if anyone has any help for you.

---

Also, you said in a previous post that there may be a problem with getting miners that function for no reward, actually, if there was no reward, regular node computers that need to run in order to host wallets could be used for the network (In a time when Bitcoin was first released, the difficulty of each block was that of the difficulty a computer could handle). If companies were to use it and were running it in order to confirm transactions that were sent to them at least then it would work with the blocks quite well.

I'm looking at Litecoin at the moment, having issues getting the Testnet blockchain to download though :/

You'd probably have to find a mining company that can mine your blocks for you as well for a subscription fee and then you won't have to pay any transaction fees (but that might be quite unlikely).
I think the Dash suggestion was due to their stansactions being much faster than bitcoin. There are other coins like doge and litecoin (doge is not used very much now but a new block can appear every 60 seconds on average so may be useful and will have small/no fees due to no one else using it very much). These three coins have been going a few years already so should be fairly secure (a similar security to bitcoin - they use most of the Bitcoin code as well).

This will definitely save you money.
You pay for the number of bytes you send. There will be a smaller amount of bytes required to make this transaction ue to there being less input scripts required and the main information required that also uses space in the transaction size.

I was going to use Bitcoin as it has the largest user base, is easy to get hold of and is unlikely to vanish any time soon. To  be honest I am considering focusing on the hardware and payment processing side, and trying to find an existing and trusted Bitcoin service provider to handle the back-end Bitcoin transactions and keeping data secure.

That is one long reply there. Anyway why have a second blockchain? You can use altcoins if you want. Roger Ver has tweeted that he has sent $100k through using Dash. The fees were costed him only a few pennies.

There is also a trustless way to do what I posted above. It is called the Lightning Network.

There seems to be a rather large dislike towards off-chain transactions and wallet services holding keys on here, but as the block reward keeps going down, fees are going to go up. Bitcoin will most likely end up as nothing but a digital gold. No-one transacts with gold any more, and the cost of doing so is too high for smaller amounts anyway.

Paying tens of dollars/pounds/whatever is OK for a transaction with a dollar/pound value of thousands, but where the technology can really show value is in smaller transactions. Burger vans, small cafe's, mobile traders etc, Bitcoin is an ideal solution for them to accept digital payments, but if the fee for a burger is a third of the price, it's not worth it. The trader won't accept that loss, and the customer won't pay that much extra either. There is also the confirmation time. You could potentially wait hours for a transaction to be confirmed if you pay the "normal" fee, if there's investors or exchanges paying higher fees to get their transactions on the chain ASAP.

It is a fairly new technology with a strong community, and a lot of places (as in real physical stores) do accept it as payment, but it's nowhere near as quick as waving my phone on a terminal and paying in 2 seconds. That's what people want. Simple, easy and fast. I'm actually putting a lot of time and money (that I  don't really have at the moment) into creating a payment system that has the convenience and speed of EMV/EFT, but also keeps away from the "PayPal for Bitcoin" concept. I even have an idea to, even in the event of all servers and backups being destroyed, give users a way to get 100% of their Bitcoin back (not accounting for pending transactions that didn't make it).

What could work as a solution is a second block chain. Optimised for fast transaction times and used for transactions between exchanges/payment processors etc. Coins mined on this chain would have no value, and it would require all participating services to partially trust each other. When a user wants to use one of the services on this chain, they would send funds to a multi-sig address with a key held by each participating service provider. The user is then given a pre-mined coin to that BTC value and it can be transacted as normal. On wanting to take funds back to the main chain, x amount of providers will have to agree that the user doesn't have any outstanding transactions to be confirmed and the amount they want to take out is correct. They then sign the TX on the main chain and the user gets their "real" Bitcoin back.

Of course, mining for no reward would be an issue, however that could be worked out, likely.

Correct me if I am wrong but there is nothing in the protocol that prevents you from making bigger transactions. And I can think of at least one transaction from 2015 that was nearly 1000000 bytes (~1 MB) and it was mined with no problem.

I had the same idea in mind when I started this thread https://bitcointalksearch.org/topic/why-i-think-blockchaininfo-is-in-a-good-position-despite-the-rising-fees-1820131

The idea is Blockchain.info will be in a good position to do something like your service but with a different model. Basically I foresee Blockchain.info will have arrangements with different Bitcoin services to process transactions with an internal ledger first. Fees will be cheaper than what your paying with present fees now. Then later Blockchain.info will settle the transactions in the blockchain by bulk.

Part of it is similar to a web wallet. Each user has their own keys and addresses rather than just a number in a database that shows how much they have. Instead of sending each transaction to the network as soon as it is made, I will add them together into one larger one saving on overhead.

The exact working out of it all is yet to be figured out. At the moment I am writing software for card terminals

This is probably not true.

It is unlikely that a for-profit business is going to spend the exact same amounts of money that they receive (otherwise you probably wouldn't be earning a profit), and as a result of this, it is likely that you will need to send a BTC to a change address for each transaction that you send. Sending to 10 change addresses in 10 transactions is going to be more expensive than sending to 1 change address in one transaction. If you split up your transactions so that you have one transaction for each payment, then you are going to have to eventually spend the money that you sent to these change addresses, which would cause you to have an additional input for each change address.

With limitations, for each transaction you can eliminate to combine multiple payments into one transaction, you will save the cost associated with one input and one output.

Sounds interesting.

I look forward to seeing what you're offering.

I'm happy to discuss your concepts and ideas with you offline if you like.

You know, I've been focussing so much on the hardware side to this I never really considered that.

It is account based, but everything still happens on the block chain. In a way that doesn't give too much information out at the moment, it takes the best bits of the Fiat banking system (no waiting for confirmations, endless methods of sending funds between accounts, both within and outside of the service and possibly a short term chargeback/transaction cancellation facility), and (unless a court warrant is provided) the anonymity of blockchain technology.

It's more of a way to provide banking type services, without the bank part, and Bitcoin is the value-carrier used. When I stop throwing boiling water all over myself (mid way through this post, boiling water and noodles straight on the frigging leg) and get some non-shite looking prototype hardware and a working back-end sorted, I'll be making a big post about it

That depends on what sort of use your service gets and how often the users use the service between sends.

If a single user wants to send 3 transactions in the same transaction generation time-period, then you could use just 1 input from that user and generate 4 outputs.

If 10 users all want to send to the same merchant (or same merchant address?) you could combine all 10 into a single output.

Are you planning on having the users fund an account with your service, and they your service draws down the account as the user requests transactions?  Or are you planning on building a transaction and sending it (unsigned) out to all the senders that are included so that they can ALL sign the transaction while you wait for them ALL to return their signatures?  What happens if someone never responds with a signature, do you try getting signatures again without their transaction?

As a side effect, it will also make the transactions much harder to trace. Although these transactions would be between users of a service, from publicly available data on the chain there is no way to know what UTXO's went to which address. Like cash in a cash register really, no way to trace which customers specific coins or notes went to which bank/supplier/petrol station/p0rn mag and tissues on company expenses.

I will end up putting a limit on TX size. I guess as part of my service provides Bitcoin facilities to point of sale and EMV hardware with fees to cover overheads, I'll arrange transactions so that I take the hit for the "overhead" fees.


Unfortunately I can't reduce the inputs. There will be a minimum of 1 input and 2 outputs per "user" transaction within this huge combined one. It's more about saving fees for merchants who accept Bitcoin than saving it for myself.

I need to do a project pre-announcement at some point, just waiting on getting a working demo sorted first

Each transaction has 10 bytes of overhead, so you'll see an immediate savings there.

Then, depending on how you are building your transactions, you may be able to reduce the number of inputs you use.  You'll see a MUCH bigger savings there, as each input will require at least 147 bytes.

Personally, I'd try to keep the transaction size below 100KB.  Larger transactions might be ok, I'm not sure, but I'm pretty confident that anything less than 100KB will be fine right now.

It will be cheaper for you to do the transactions as one large transaction as that cuts out the overhead required for making multiple transactions. It also reduces the risk of having long unconfirmed transaction chains which can be very problematic for the people receiving the Bitcoin.

Regarding the size of the transaction, 500 Kb is quite large. If your transaction is going to be that big, you should probably split it up into multiple transactions.