The LTB Network Forum

It's Expensive Using Bitcoin!

Back to LTBcoin Talk

Comments

• William

  

  Offline
  Posts: 308

  @adam

  @doogy

  @william Seems like this is a tradeoff for using counterparty on the BitCoin blockchain... If these fees can't be controlled it could really make this project difficult in the long run. Theoretically, could LTBcoin be migrated away from counterparty to a different protocol, if needed at some point in the future?

  I was also going to suggest the delivery tax thing until I saw this idea which got me thinking. Do you mean you would move it to litecoin blockchain lets say for the sake of this argument? or where you thinking a different platform on the bitcoin blockchain?

  Not litecoin... But there is another

  I was thinking something like NXT -- though I have not played around with it and don't know about their transaction fees. Adam, tell us, what is the other you are mysteriously alluding to?

  Posted on July 8, 2014 at 7:25 AM
  Permalink
  0 likes
• cmason

  

  Offline
  Posts: 119

  Obviously LeiaCoin. :)

  Posted on July 8, 2014 at 7:33 AM
  Permalink
  0 likes
• CrimsonRoze

  

  Offline
  Posts: 295
  Location: Göteborg, Sweden

  One option to reduce cost (and security) would be to apply the counterparty protocol on top of another coins blockchain where the transaction costs are lower.

  Also I'm not sure fee's are guaranteed to rise with the new fee model. And even if it does, whenever we get a solution to the costs of block distribution and allow larger blocks the fees should go down again.

  Posted on July 8, 2014 at 7:55 AM
  Permalink
  0 likes
• William

  

  Offline
  Posts: 308

  @cmason

  Obviously LeiaCoin. :)

  As in PrincessLeiaCoin? :)

  Posted on July 8, 2014 at 8:23 AM
  Permalink
  0 likes
• William

  

  Offline
  Posts: 308

  @crimsonroze One option to reduce cost (and security) would be to apply the counterparty protocol on top of another coins blockchain where the transaction costs are lower.

  Also I'm not sure fee's are guaranteed to rise with the new fee model. And even if it does, whenever we get a solution to the costs of block distribution and allow larger blocks the fees should go down again.

  Well, I think counterparty is open source, so this should be technically possible. And also, building on another blockchain could increase speed greatly, right? But then don't you loose the security advantages of building on BTC? And also, wouldn't that drastically increase the amount of work needed to be done by the LTB community, because it would essentially have to develop that fork of counterparty? I'm not a programmer, so this is mostly guesswork...

  Posted on July 8, 2014 at 8:27 AM
  Permalink
  0 likes
• adam

  

  Offline
  Posts: 1980
  Location: California, USA

  woof

  Posted on July 8, 2014 at 8:29 AM
  Permalink
  2 likes
• CrimsonRoze

  

  Offline
  Posts: 295
  Location: Göteborg, Sweden

  Regardless of how we solve this particular issue for this particular usecase, if we still have a high base fee in the bottom of the structure and scale up, then this will never work out.

  So how do we get the base cost lower? Even if there was a way to group up all the transactions in to a single one, the sheer data size of the addresses alone is an issue.

  Storing the blockchain is rather cheap today even though it's soon 20gb in size (harddrives are cheap). Broadcasting the transactions and blocks today is relatively cheap (bitcoin volume still fits nicely in most consumer internet connections).

  Should the bitcoin volume go up much faster than the development of faster internet and larger harddrives though, then fees is supposed to be the filtering mechanism between the transactions that are valued and useful to people and the transactions that are (subjectively) less valued and useful.

  Could it be that we are seeing the limits of the current architecture for bitcoin by pushing its boundaries with counterparty?

  Here's a crazy idea that may or may not have merit (I dont know how counterparty transactions look like):

  If the counterparty transactions are sent and handled in clear-text, compress them. If the order of the components inside the transactions are not important, randomly re-organize them to achieve better compression ratios. (trial and error procedure, costs CPU power but could save storage and network utilization)

  Posted on July 8, 2014 at 8:52 AM
  Permalink
  1 like
• William

  

  Offline
  Posts: 308

  @adam woof

  mmmm. doge. Would this involve counterparty changing blockchains, or would it be a counterparty fork?

  Posted on July 8, 2014 at 8:59 AM
  Permalink
  0 likes
• deweller

  

  Offline
  Posts: 347
  Location: Nashville, TN

  I think the issue is that each counterparty "SEND" transaction is separate. There is no way to send to 2 different addresses in one transaction.

  So, you cannot save space by compressing a data stream with multiple sends because they must remain independent from each other and live as separate entities on the Bitcoin block chain.

  Posted on July 8, 2014 at 9:00 AM
  Permalink
  0 likes
• Cryptonaut

  

  Offline
  Posts: 1944
  Location: Canada

  @deweller I think the issue is that each counterparty "SEND" transaction is separate. There is no way to send to 2 different addresses in one transaction.

  So, you cannot save space by compressing a data stream with multiple sends because they must remain independent from each other and live as separate entities on the Bitcoin block chain.

  Exactly. But the thing is, it appears that asset dividends are paid using a single transaction, so that makes me wonder why couldnt a general multi-send be in one tx? If they built something like this into the protocol that would basically solve it. not sure how feasible that is though

  Posted on July 8, 2014 at 9:07 AM
  Permalink
  0 likes

Post Reply