From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F0F771 for ; Thu, 4 Aug 2016 00:59:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1266C198 for ; Thu, 4 Aug 2016 00:59:23 +0000 (UTC) Received: by mail-qk0-f170.google.com with SMTP id p186so93437751qkd.1 for ; Wed, 03 Aug 2016 17:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZcKacb0OJYmKRmwXleoQvBxnP/r6BrQSQHiPX6EB7NY=; b=tHf58oHT0l6pUfSohkCGN0icvrMck9rMmBC56/d4hcwzyCNkMT2RdGgQ50UKeDfNK5 RLvS95SGtuO+VSB2/K+5J9RDGXnBoxjlYtA0Z9hvOOwCnqmUtncFcAbAmryseVzctPof /lRv8CF5XsDBmIjDNOSJTpaMwfeXyM5XUd+8+eIJtFk5Oas7C626/lu5vqEikZif48oI l2sLhpHVqvMPb+IQ941IvUMxsQJY0yxwmk9eNw6EitEf37wsjCdJbbsGfYPSSAfUfP+f 84+WOVrRjFBEy2A7xtniQsnWl/YF6PpiLd6T4qu4Dpl8YAoUC+bcn1Ah0xRMDYll3tIq hw+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZcKacb0OJYmKRmwXleoQvBxnP/r6BrQSQHiPX6EB7NY=; b=Xd5VAQ5gTXNDo2fh/B1qyAnmRBVh+6Ja4gU9W5Z0WjF/1rqzqef4QaZSEaDQsj3x0g VXvilYnHeoV6L6dI81t0/8QfbRDL+3c4yGNCDttThY3EMp9GSQjRE1bLpmXy+e0dzbvc dnTXFmSol7jO27CtA2lJJjIttXyYU3unph02yRcaOSolzNCtw2czFqZlXX8dlWie1N+N Q/A7nAULHiOOTa2GGZwpFF9ABwoKbBznGKEGQVJqjVxK6PbyAzafSPq2Ss3lv2mSqPFp dY9U0yyAd9/h4Vrfd6dTl5bOacs8W0y8Au/RnHgWW90/HFVy7JEpvwO3JnT0NtX7hqgV p03g== X-Gm-Message-State: AEkooutD+UjoE41EpgrtBfjY9ls9T6z5iRgusesLaOeEkD+Lvq+pspPx3CUJEteFjuJ6vVZtTEiGoDJtYKUnCA== X-Received: by 10.55.221.85 with SMTP id n82mr3108637qki.236.1470272362140; Wed, 03 Aug 2016 17:59:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: James MacWhyte Date: Thu, 04 Aug 2016 00:59:11 +0000 Message-ID: To: Marc Larue Content-Type: multipart/alternative; boundary=001a1149d1dede5e140539347515 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Fees and Accounts X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 00:59:24 -0000 --001a1149d1dede5e140539347515 Content-Type: text/plain; charset=UTF-8 > 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 > > 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 > > > > > > > --001a1149d1dede5e140539347515 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Most people?
I'm talking ab= out services that are built to handle multiple accounts, like exchanges and= payment processors.
=C2=A0
Y= ou 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 li= st from the latest block, and check each confirmed transaction against your= database of receive/watch addresses. If there is a match, you record the t= ransaction info in your database so you can use it as an input later to cre= ate a spend transaction.

You could also use something like Bitpay= 9;s Insight to make interfacing with bitcoind easier.
=C2=A0
It can't possibly scale, also we don't have the time to build an ac= count
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?=C2=A0
=C2=A0
Also external systems are not be trusted, specially not bitgo, did you
read any news in the last 24 hours?
I prefer to wait u= ntil all facts are in before I pass judgement. I think BitGo is an excellen= t company with a great track record. If used properly, they are extremely s= ecure. If you are worried about storing funds there long time, don't--j= ust use them to detect incoming payments and move your funds elsewhere for = long term storage.
=C2=A0
/m

On Wed, 3 Aug 2016, James MacWhyte wrote:

>
> From what I've seen, most people build their own account system se= parately
> (including fee management) and just use bitcoind to send, receive, and=
> verify transactions. It's not meant to be a drop-in solution for r= unning an
> entire bitcoin deposit and withdrawal system, it just provides the bar= e
> tools required to build your own. If you need a pre-built solution, th= ere
> are companies that provide those types of services as a platform (BitG= o, for
> example).
>
>
> On Wed, Aug 3, 2016, 11:25 Marc Larue via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I have 2 problems with bitcoind that separat= ely are not a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0problem but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0together they make the platform unusable for= many projects.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If I have accounts I need to make sure the a= ccount holders do
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0overcharge their account. To do this I can n= ow use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"createrawtransaction()
>=C2=A0 =C2=A0 =C2=A0 =C2=A0+ fundrawtransaction() + signrawtransaction(= )" and then make
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sure the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0transaction can be paid by an account.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0But since you deprecated the accounts and th= ere is no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sendrawtransactionfrom() method; I either ha= ve to build my own
>=C2=A0 =C2=A0 =C2=A0 =C2=A0account
>=C2=A0 =C2=A0 =C2=A0 =C2=A0system (this is no picknick btw, since you n= eed to track all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0incoming
>=C2=A0 =C2=A0 =C2=A0 =C2=A0funds to all addresses and having an integra= ted account system
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in bitcoind
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is 100% necessary to do this effectively). >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Or I might be able to go ahead and speculate= that you will not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be able to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0untangle the account code and hack my bitcoi= nd to have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sendfrom with a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0fixed fee parameter that overrides the size = multiplication and I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0just do
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the math before I send hoping that the trans= actions go through
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(this is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bad but better than having accounts overchar= ge because they send
>=C2=A0 =C2=A0 =C2=A0 =C2=A0dust that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0induce high fees).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I understand the privacy problems with using= accounts for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0off-chain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0microstransactions but currently it's th= e best workable option.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I hope you understand that I'm not troll= ing here, I have been
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mining since
>=C2=A0 =C2=A0 =C2=A0 =C2=A02011 on FPGAs and built bitcoinbankbook.com= 2 years ago. When I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0descovered
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that once transactions will require fees (ba= ck then they didn't)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0your system is not able to handle fees with = accounts, I stopped
>=C2=A0 =C2=A0 =C2=A0 =C2=A0developing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0everything related to bitcoin.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0There are probably 100s if not 1000s of deve= lopers in the same
>=C2=A0 =C2=A0 =C2=A0 =C2=A0situation.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You can't just deprecate accounts like t= hat because nobody likes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the code.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Without accounts bitcoind is only a person-t= o-person manual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0client.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To build many-to-many automatic "organi= sations" on top of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoind you
>=C2=A0 =C2=A0 =C2=A0 =C2=A0need accounts and you need fees that are pre= dictable.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Kind Regards,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/marc
>=C2=A0 =C2=A0 =C2=A0 =C2=A0____________________________________________= ___
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin-dev mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin-dev@lists.linuxfoundation.org >=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
--001a1149d1dede5e140539347515--