public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: James MacWhyte <macwhyte@gmail.com>
To: Marc Larue <marc@rupy.se>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and Accounts
Date: Thu, 04 Aug 2016 00:59:11 +0000	[thread overview]
Message-ID: <CAH+Axy7HE7+spU+7Ken5akgrQFecV_VtjwPCbpJv0xvkGBrkqQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1608032202340.4704@rupy.se>

[-- 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 --]

      parent reply	other threads:[~2016-08-04  0:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH+Axy7HE7+spU+7Ken5akgrQFecV_VtjwPCbpJv0xvkGBrkqQ@mail.gmail.com \
    --to=macwhyte@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=marc@rupy.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox