public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] Fees and Accounts
@ 2016-08-03  9:53 Marc Larue
  2016-08-03 18:33 ` James MacWhyte
  0 siblings, 1 reply; 3+ messages in thread
From: Marc Larue @ 2016-08-03  9:53 UTC (permalink / raw)
  To: bitcoin-dev

Hi,

I have 2 problems with bitcoind that separately are not a problem but
together they make the platform unusable for many projects.

If I have accounts I need to make sure the account holders do not 
overcharge their account. To do this I can now use "createrawtransaction() 
+ fundrawtransaction() + signrawtransaction()" and then make sure the
transaction can be paid by an account.

But since you deprecated the accounts and there is no
sendrawtransactionfrom() method; I either have to build my own account
system (this is no picknick btw, since you need to track all incoming 
funds to all addresses and having an integrated account system in bitcoind 
is 100% necessary to do this effectively).

Or I might be able to go ahead and speculate that you will not be able to
untangle the account code and hack my bitcoind to have a sendfrom with a
fixed fee parameter that overrides the size multiplication and I just do
the math before I send hoping that the transactions go through (this is 
bad but better than having accounts overcharge because they send dust that 
induce high fees).

I understand the privacy problems with using accounts for off-chain
microstransactions but currently it's the best workable option.

I hope you understand that I'm not trolling here, I have been mining since
2011 on FPGAs and built bitcoinbankbook.com 2 years ago. When I descovered
that once transactions will require fees (back then they didn't) and that
your system is not able to handle fees with accounts, I stopped developing
everything related to bitcoin.

There are probably 100s if not 1000s of developers in the same situation.

You can't just deprecate accounts like that because nobody likes the code.
Without accounts bitcoind is only a person-to-person manual client.

To build many-to-many automatic "organisations" on top of bitcoind you 
need accounts and you need fees that are predictable.

Kind Regards,

/marc


^ permalink raw reply	[flat|nested] 3+ messages in thread

• * Re: [bitcoin-dev] Fees and Accounts
    2016-08-03  9:53 [bitcoin-dev] Fees and Accounts Marc Larue
  @ 2016-08-03 18:33 ` James MacWhyte
         [not found]   ` <alpine.LNX.2.00.1608032202340.4704@rupy.se>
    0 siblings, 1 reply; 3+ messages in thread
  From: James MacWhyte @ 2016-08-03 18:33 UTC (permalink / raw)
    To: Marc Larue, Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 2736 bytes --]
  
  From what I've seen, most people build their own account system separately
  (including fee management) and just use bitcoind to send, receive, and
  verify transactions. It's not meant to be a drop-in solution for running an
  entire bitcoin deposit and withdrawal system, it just provides the bare
  tools required to build your own. If you need a pre-built solution, there
  are companies that provide those types of services as a platform (BitGo,
  for example).
  
  On Wed, Aug 3, 2016, 11:25 Marc Larue via bitcoin-dev <
  bitcoin-dev@lists•linuxfoundation.org> wrote:
  
  > Hi,
  >
  > I have 2 problems with bitcoind that separately are not a problem but
  > together they make the platform unusable for many projects.
  >
  > If I have accounts I need to make sure the account holders do not
  > overcharge their account. To do this I can now use "createrawtransaction()
  > + fundrawtransaction() + signrawtransaction()" and then make sure the
  > transaction can be paid by an account.
  >
  > But since you deprecated the accounts and there is no
  > sendrawtransactionfrom() method; I either have to build my own account
  > system (this is no picknick btw, since you need to track all incoming
  > funds to all addresses and having an integrated account system in bitcoind
  > is 100% necessary to do this effectively).
  >
  > Or I might be able to go ahead and speculate that you will not be able to
  > untangle the account code and hack my bitcoind to have a sendfrom with a
  > fixed fee parameter that overrides the size multiplication and I just do
  > the math before I send hoping that the transactions go through (this is
  > bad but better than having accounts overcharge because they send dust that
  > induce high fees).
  >
  > I understand the privacy problems with using accounts for off-chain
  > microstransactions but currently it's the best workable option.
  >
  > I hope you understand that I'm not trolling here, I have been mining since
  > 2011 on FPGAs and built bitcoinbankbook.com 2 years ago. When I descovered
  > that once transactions will require fees (back then they didn't) and that
  > your system is not able to handle fees with accounts, I stopped developing
  > everything related to bitcoin.
  >
  > There are probably 100s if not 1000s of developers in the same situation.
  >
  > You can't just deprecate accounts like that because nobody likes the code.
  > Without accounts bitcoind is only a person-to-person manual client.
  >
  > To build many-to-many automatic "organisations" on top of bitcoind you
  > need accounts and you need fees that are predictable.
  >
  > Kind Regards,
  >
  > /marc
  > _______________________________________________
  > bitcoin-dev mailing list
  > bitcoin-dev@lists•linuxfoundation.org
  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  >
  
  [-- Attachment #2: Type: text/html, Size: 3445 bytes --]
  
  ^ permalink raw reply	[flat|nested] 3+ messages in thread

• • [parent not found: <alpine.LNX.2.00.1608032202340.4704@rupy.se>]

  • • * Re: [bitcoin-dev] Fees and Accounts
             [not found]   ` <alpine.LNX.2.00.1608032202340.4704@rupy.se>
      @ 2016-08-04  0:59     ` James MacWhyte
        0 siblings, 0 replies; 3+ messages in thread
      From: James MacWhyte @ 2016-08-04  0:59 UTC (permalink / raw)
        To: Marc Larue; +Cc: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 4886 bytes --]
      
      > Most people?
      
      I'm talking about services that are built to handle multiple accounts, like
      exchanges and payment processors.
      
      
      > You realize that you need to set up bitcoind to make an
      > external request on every reception of funds on any address in the whole
      > system.
      >
      No, you don't. You can write a script that repeatedly asks bitcoind for the
      block height, and when it increments you know a new block has been
      confirmed. So then you request the transaction list from the latest block,
      and check each confirmed transaction against your database of receive/watch
      addresses. If there is a match, you record the transaction info in your
      database so you can use it as an input later to create a spend transaction.
      
      You could also use something like Bitpay's Insight to make interfacing with
      bitcoind easier.
      
      
      > It can't possibly scale, also we don't have the time to build an account
      > system for every bitcoind service. Imagine the loss of time, it's huge and
      > grows exponentially with adoption, or rather there is no adoption!
      >
      What are you trying to build?
      
      
      > Also external systems are not be trusted, specially not bitgo, did you
      > read any news in the last 24 hours?
      >
      I prefer to wait until all facts are in before I pass judgement. I think
      BitGo is an excellent company with a great track record. If used properly,
      they are extremely secure. If you are worried about storing funds there
      long time, don't--just use them to detect incoming payments and move your
      funds elsewhere for long term storage.
      
      
      > /m
      >
      > On Wed, 3 Aug 2016, James MacWhyte wrote:
      >
      > >
      > > From what I've seen, most people build their own account system
      > separately
      > > (including fee management) and just use bitcoind to send, receive, and
      > > verify transactions. It's not meant to be a drop-in solution for running
      > an
      > > entire bitcoin deposit and withdrawal system, it just provides the bare
      > > tools required to build your own. If you need a pre-built solution, there
      > > are companies that provide those types of services as a platform (BitGo,
      > for
      > > example).
      > >
      > >
      > > On Wed, Aug 3, 2016, 11:25 Marc Larue via bitcoin-dev
      > > <bitcoin-dev@lists•linuxfoundation.org> wrote:
      > >       Hi,
      > >
      > >       I have 2 problems with bitcoind that separately are not a
      > >       problem but
      > >       together they make the platform unusable for many projects.
      > >
      > >       If I have accounts I need to make sure the account holders do
      > >       not
      > >       overcharge their account. To do this I can now use
      > >       "createrawtransaction()
      > >       + fundrawtransaction() + signrawtransaction()" and then make
      > >       sure the
      > >       transaction can be paid by an account.
      > >
      > >       But since you deprecated the accounts and there is no
      > >       sendrawtransactionfrom() method; I either have to build my own
      > >       account
      > >       system (this is no picknick btw, since you need to track all
      > >       incoming
      > >       funds to all addresses and having an integrated account system
      > >       in bitcoind
      > >       is 100% necessary to do this effectively).
      > >
      > >       Or I might be able to go ahead and speculate that you will not
      > >       be able to
      > >       untangle the account code and hack my bitcoind to have a
      > >       sendfrom with a
      > >       fixed fee parameter that overrides the size multiplication and I
      > >       just do
      > >       the math before I send hoping that the transactions go through
      > >       (this is
      > >       bad but better than having accounts overcharge because they send
      > >       dust that
      > >       induce high fees).
      > >
      > >       I understand the privacy problems with using accounts for
      > >       off-chain
      > >       microstransactions but currently it's the best workable option.
      > >
      > >       I hope you understand that I'm not trolling here, I have been
      > >       mining since
      > >       2011 on FPGAs and built bitcoinbankbook.com 2 years ago. When I
      > >       descovered
      > >       that once transactions will require fees (back then they didn't)
      > >       and that
      > >       your system is not able to handle fees with accounts, I stopped
      > >       developing
      > >       everything related to bitcoin.
      > >
      > >       There are probably 100s if not 1000s of developers in the same
      > >       situation.
      > >
      > >       You can't just deprecate accounts like that because nobody likes
      > >       the code.
      > >       Without accounts bitcoind is only a person-to-person manual
      > >       client.
      > >
      > >       To build many-to-many automatic "organisations" on top of
      > >       bitcoind you
      > >       need accounts and you need fees that are predictable.
      > >
      > >       Kind Regards,
      > >
      > >       /marc
      > >       _______________________________________________
      > >       bitcoin-dev mailing list
      > >       bitcoin-dev@lists•linuxfoundation.org
      > >       https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      > >
      > >
      > >
      >
      
      [-- Attachment #2: Type: text/html, Size: 6790 bytes --]
      
      ^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-08-04  0:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-03  9:53 [bitcoin-dev] Fees and Accounts Marc Larue
2016-08-03 18:33 ` James MacWhyte
     [not found]   ` <alpine.LNX.2.00.1608032202340.4704@rupy.se>
2016-08-04  0:59     ` James MacWhyte

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox