[REQ] Send-to-Many in a single tx

Did you keep confirmation delay stats?
I think there were reports that most transactions go through, but not all. And some take a very long time, so it creates “support issues”.

Usually within the first two blocks. I haven’t analyzed it formally though.

That’d be a nice little experiment. I might give it a try in coming days.

We played with miners fees a lot in the early days and while yes you can get away with lower or even no fee transactions under certain conditions, that all falls apart when you’ve sending several thousand transactions.

Also I believe our miner fee is somewhat below that figure, for the last six months or so we’ve been using .00006btc per fee

There is still a cost, no doubt but we’ve been distributing to more than a thousand people weekly for the last year and haven’t felt it was even a significant cost worth thinking much about considering how much trouble it saves us. It’s automatic and it’s cheaper than you can send from a default wallet by yourself

Yes, it only cost 0.00006 per transaction.

This distributor does about 1400 per week for LTBCOIN and 200 per day for FLDC, so weekly this things cranks out almost 3000 per week :smiley:

im on it :smiley:

IMO - Most people aren’t using counterparty in a sustainable way when broadcasting so many transactions. It’s great for our stats that people are doing this, so I’m certainly not complaining. But The counterparty risk between you and your depositor, for your own token, is very low.

Probably the value exports should only be performed when the user wishes to exit your bank (and settle to a bearer bond) and/or when your bank wishes to transmit value to another bank (ie, Folding Coin to LTB).

If the cost of risk reduction at 3 cents per transaction is too high, it’s probable that there’s not much risk in the nature of this settlement.

We don’t want to be banks for customer value, all our systems are designed to just reference user addresses and put the control and private keys and tokens in their hands.

We have made a compromise at LTB, we only distribute weekly. FLDC distributes twice a day, we’ve suggested it would be more efficient to move to weekly distributions but they like the immediacy and don’t think the cost is too much to pay.

I’m a little suprised you think offchain systems are trustworthy, didn’t we already see this movie with every web wallet ever that was hacked and looted?

We’re a pinata no matter what we do but we can control how much good stuff is inside in case someone breaks us open. Tokenly and LTB always want to be the smallest stingiest pinata, so on-chain makes it not our problem and supports bitcoin with real transactions that pay fees and are not for test purposes.

Am I crazy? How can you suggest we go offchain when the cost of being onchain is not bothering the two largest users comprising more than 60% of total counterparty transactions between them?

I agree with adam on this one. I think off chain will be good for mainstream adoption for many things such as web wallets. However, with rewards systems and payments, I would not have it any other way then doing the distributions how we do them now.

We have discussed in the past doing a database “off chain distribution system”, but we always come back to the same question: what if someone hacks our database? Now we could resolve this by rolling back the database, but thats just a headache. the way we do the FLDC distribution is in the absolute most secure way. My distribution machine has all websites blocked except counterwallet and foldingcoin.net and we switch the keys around every 28 days. I feel 100% confident that this system cant be hacked, but us hosting an off chain system could be.

Perhaps when we are bigger we may have to explore off chain options, but as i see it now this is by far the best solution we have.

ADDED: Also i was getting to thinking, if someone does have a use for an offchain system integrated with the share distributoe they could do this:

when the user decides to settle with the “bank” then these settlements could be added up collective until the end of the day and the user would know that they will not be paid out until a certain time. Then you the “bank” would just add all of these withdraws up and still use the share distributor as the cost for sending is still incredibly low.

But with this scenerio you still have database breach concerns, there is no way around that

Also its only 1.5 cents

I don’t see the problem as long as they are aware that fees eventually will rise. If anything, I think making many transactions is good for Counterparty and Bitcoin. In the not-too-distant future, when blocks are getting saturated, services like LTB and FLDC will, I suppose, adapt partially by increasing tx fees and partially by broadcasting less transactions. This in turn will be good for Bitcoin as it will smooth out the transition to a market based fee structure.

Our current plan is to move low value stuff to dogeparty which is why I was involved with its launch last year, it’s an order of magnitude cheaper and block speed is irrelevent in tokenly systems since we base user interactions on the principle of conclude-customer-interaction-on-announce and follow with confirmations via email.

For reference Dogeparty was launched primarily with “a token for every twitter user to call their own and tip others with” as the goal so you can imagine how cheap all those assets and transactions would need to be. Offchain solutions are not bitcoin, onchain solutions are so in this case I think offloading low value stuff to Dogeparty is way more consistent with the project ethos than moving to offchain systems where all kinds of schenanagins can happen.

Banks are typically trustworthy when they’re insured, and risk is normalized over a large number of participants. This is one reason why fiat banks have a stellar record in protecting their deposits, whilst ours do not. Though Bitcoin presents some risks than are not present in fiat systems, I would suggest that this is the primary reason we’ve had MT Gox-level problem and exit scams.

Since you’re the issuer of a token, you probably haven’t mitigated the security issues all that much merely by settling all value on the chain. (Though you would if you were not the issuer) Presumably, the difficulty in compromising and issuing more LTBCOIN is comparable to breaking into a bank of LTBCOIN and siphoning deposits. I think the distinction to note with assets, that make them very different than Bitcoin, is that assets are usually some form of credit, whereas Bitcoin is value. As such, you the issuer always carry an inordinate security burden.

I think a great product to offer (particularly to game devs) would be a SaaS that manages scarcity off-chain via an API, and which offers inter-bank and on-chain settlement services (via Counterparty of course) as part of the offering.

One of the nice security benefits of being off-chain provider, is that if you are compromised, and settlement functions are well segmented from the rest of the system, you can always restore user balances from a backup.

At the moment, we’re fine, and I think these transaction counts are great for our stats. It’s over time that I feel it may not be sustainable. As more companies join counterparty, should the network volume quadruple or more - do you still think you could afford the fees, given the same block size constraint?

At some point, we may end up supporting Lightning Network with Counterparty, and that would enable the current system to continue. But, again, if risk is well-managed and/or insured, you may find that the benefits of centralized banking is more efficient.

Wait, didn’t you just say in the last post that "How can you suggest we go offchain when the cost of being onchain is not bothering the two largest users "? If you’re moving to dogeparty, then clearly this cost is burdening one of those users.

Dogeparty is poorly developed, and the doge chain is a mess. You will come to find that the cost to support your ambitions on the doge chain are not unsubstantial, and that the counterparty risk in these transactions were minimal to none. I would similarly suggest that Litecoin halving day is coming up soon (You know - because Doge’s chain already failed), and the potential of this chain forking is probably an unwise risk to bear at this stage.

I’d suggest waiting to see if Litecoin withstands halving before investing any development time and money into its chain. Remember that all the time and money you put into the dogechain - comes at consequence from your core product. If you don’t need immutability, you should be managing value centrally, and settling when users and banks require settlement.

Can you show me what one of these transactions look like in blockchain.info? The problem with concatenating many destinations into a single transaction is that you begin to limit what you can do on resource-restricted platforms. We don’t have an SPV mode, but one thing we do have is an "event’ that fires everytime an asset hits a public address. This enables some forms of operations to be optimized to not have to query a counterparty server until an address is marked ‘dirty’. (as in - in receipt of a message).

PhantomPhreak’s point above is that even if we combined multiple outputs into a single transaction, you wouldn’t save much money. This sounds about right to me, if we could see one of the colored coin transactions being referenced, we could do the math.

We’re not moving to Dogeparty, I said that is the plan is to move to Dogeparty (or bitshares assets or something else that works to fit our needs when it gets too expensive to continue on Bitcoin). Right now it makes sense to do anything with a minimum value of at least 10 cents which is still cheaper than any other commerce platform one can imagine. I don’t anticipate it becoming a problem because the bitcoin fee will be lowered as the price goes up and we’ll adjust our nominal bitcoin amount down.

If bitcoin is successful and blocks do not increase in size people will have a choice to go off-chain or to another chain. We would go to another chain, there are many companies out there offering inexpensive private blockchains that would not be difficult to integrate into a bitcoin compatible wallet.

I really find it painful to talk to you Chris, you’re just so wrong and proud that you’re uninvolved with the project beyond promoting it. You said you’re a developer, doesn’t look like you’ve done much for Counterparty or anything else on Github so far. Any features or fixes you’re planning to tackle?

Colored Coins use a colored UTXO approach rather than an account based approach so each chunk of colored coins are a specific bitcoin utxo. If bitcoin can do send-to-many than so can colored coins because fundamentally its just a bitcoin transaction that includes specific colored UTXOs.

Counterparty cannot do this because it is not UTXO based rather each counterparty transfer is a change-order submitted to the blockchain.

The value of your economies is contingent on your existence. If your users can’t trust you to hold their coins off chain, then you have other projects. It’s true, you don’t need to distribute like you do. You could even let users who want to export their ltb or fldc off chain by having them fund the utxo. I bet users would be willing to do that considering it’s 3 cents. What you should probably focus on is determining how to let people transact using your economy within your eco system. Most of your economy can probably be taken off chain. I’m amazed that y’all are so resistant to the idea.

That’s absurd. There is no efficiency here over a centralized database. Who’s going to mine this chain? Is it trust-based? Then, you know, there’s no counterparty risk. You will regress towards mysql or riak with such an approach. Are you trying to offer a market efficiency, or an ideologically aligned platform?

I am a programmer, but a lazy one :slight_smile: I’d love to tackle Counterparty dev more, but haven’t had the time. I may choose not to run as community director next year and devote my bitcoin-fun time to dev time. Until then, you’ll be stuck debating my forecasts.

I’m sorry, but I simply don’t understand what you’re saying. I am the Community Director of the Counterparty project. I spend my time on the Counterparty project. That’s why I chose to be the director. Of the Counterparty project. If I worked on another project, you know, I’d be the director of that project. I don’t know what you’re trying to express, other than I should be spending less time on Counterparty. But you know, … I’m a director. :slight_smile:

Counterparty could do this, by also sending multiple outputs in a transaction, augmented by the metadata that was needed to augment the transaction. PhantomPhreak’s point was that this wouldn’t offer much of a cost savings. (Which I would actually like to verify)