James MacWhyte [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-03 📝 Original message:> Most people? I'm talking ...
📅 Original date posted:2016-08-03
📝 Original message:> 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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/f3ae45ea/attachment.html>;
📝 Original message:> 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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/f3ae45ea/attachment.html>;