Return-Path: <keatonatron@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F0F771 for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; Thu, 4 Aug 2016 00:59:23 +0000 (UTC) Received: by mail-qk0-f170.google.com with SMTP id p186so93437751qkd.1 for <bitcoin-dev@lists.linuxfoundation.org>; 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: <alpine.LNX.2.00.1608031152530.359@rupy.se> <CAH+Axy5jSRVbAw_MaJArYp9_nTB8Ws6QZ5hoq4rfBZw80RciFA@mail.gmail.com> <alpine.LNX.2.00.1608032202340.4704@rupy.se> In-Reply-To: <alpine.LNX.2.00.1608032202340.4704@rupy.se> From: James MacWhyte <macwhyte@gmail.com> Date: Thu, 04 Aug 2016 00:59:11 +0000 Message-ID: <CAH+Axy7HE7+spU+7Ken5akgrQFecV_VtjwPCbpJv0xvkGBrkqQ@mail.gmail.com> To: Marc Larue <marc@rupy.se> 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 <bitcoin-dev@lists.linuxfoundation.org> 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 > > <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 > > > > > > > --001a1149d1dede5e140539347515 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr"><br></div><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex">Most people?</blockquote><div>I'm talking ab= out services that are built to handle multiple accounts, like exchanges and= payment processors.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Y= ou realize that you need to set up bitcoind to make an<br> external request on every reception of funds on any address in the whole<br= > system.<br></blockquote><div>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.<br><br>You could also use something like Bitpay= 9;s Insight to make interfacing with bitcoind easier.</div><div>=C2=A0</div= ><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1= px #ccc solid;padding-left:1ex"> It can't possibly scale, also we don't have the time to build an ac= count<br> system for every bitcoind service. Imagine the loss of time, it's huge = and<br> grows exponentially with adoption, or rather there is no adoption!<br></blo= ckquote><div>What are you trying to build?=C2=A0</div><div>=C2=A0</div><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> Also external systems are not be trusted, specially not bitgo, did you<br> read any news in the last 24 hours?<br></blockquote><div>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.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> /m<br> <br> On Wed, 3 Aug 2016, James MacWhyte wrote:<br> <br> ><br> > From what I've seen, most people build their own account system se= parately<br> > (including fee management) and just use bitcoind to send, receive, and= <br> > verify transactions. It's not meant to be a drop-in solution for r= unning an<br> > entire bitcoin deposit and withdrawal system, it just provides the bar= e<br> > tools required to build your own. If you need a pre-built solution, th= ere<br> > are companies that provide those types of services as a platform (BitG= o, for<br> > example).<br> ><br> ><br> > On Wed, Aug 3, 2016, 11:25 Marc Larue via bitcoin-dev<br> > <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D= "_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi,<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0I have 2 problems with bitcoind that separat= ely are not a<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0problem but<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0together they make the platform unusable for= many projects.<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0If I have accounts I need to make sure the a= ccount holders do<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0not<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0overcharge their account. To do this I can n= ow use<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"createrawtransaction()<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+ fundrawtransaction() + signrawtransaction(= )" and then make<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0sure the<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0transaction can be paid by an account.<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0But since you deprecated the accounts and th= ere is no<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0sendrawtransactionfrom() method; I either ha= ve to build my own<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0account<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0system (this is no picknick btw, since you n= eed to track all<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0incoming<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0funds to all addresses and having an integra= ted account system<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0in bitcoind<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0is 100% necessary to do this effectively).<b= r> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Or I might be able to go ahead and speculate= that you will not<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0be able to<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0untangle the account code and hack my bitcoi= nd to have a<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0sendfrom with a<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0fixed fee parameter that overrides the size = multiplication and I<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0just do<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0the math before I send hoping that the trans= actions go through<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(this is<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bad but better than having accounts overchar= ge because they send<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0dust that<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0induce high fees).<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0I understand the privacy problems with using= accounts for<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0off-chain<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0microstransactions but currently it's th= e best workable option.<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0I hope you understand that I'm not troll= ing here, I have been<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mining since<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A02011 on FPGAs and built <a href=3D"http://bi= tcoinbankbook.com" rel=3D"noreferrer" target=3D"_blank">bitcoinbankbook.com= </a> 2 years ago. When I<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0descovered<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0that once transactions will require fees (ba= ck then they didn't)<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0and that<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0your system is not able to handle fees with = accounts, I stopped<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0developing<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0everything related to bitcoin.<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0There are probably 100s if not 1000s of deve= lopers in the same<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0situation.<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0You can't just deprecate accounts like t= hat because nobody likes<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0the code.<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Without accounts bitcoind is only a person-t= o-person manual<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0client.<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0To build many-to-many automatic "organi= sations" on top of<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoind you<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0need accounts and you need fees that are pre= dictable.<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Kind Regards,<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0/marc<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0____________________________________________= ___<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin-dev mailing list<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:bitcoin-dev@lists.linuxfou= ndation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br= > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https:/= /lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> ><br> ><br> ><br> </blockquote></div></div> --001a1149d1dede5e140539347515--