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