* [Bitcoin-development] [RFC] listtransactions reformatting
@ 2011-07-16 17:14 Luke-Jr
2011-07-16 19:59 ` Stéphane Gimenez
0 siblings, 1 reply; 5+ messages in thread
From: Luke-Jr @ 2011-07-16 17:14 UTC (permalink / raw)
To: Bitcoin Dev
Example patch: http://tinyurl.com/6679go5
Changes:
* Additions to your wallet always are category:"receive", no matter what kind
of transaction
* Generated coins have an extra key, from:"generation"
* All transactions have a new key, status:
* "orphan" -- Another block chain invalidated this transaction (only for
generation?)
* "validating" -- Default stage for transactions; 0-2 confirmations for
ordinary sends, and 0-100 for generated coins
* "processing" -- 3-6 confirms for ordinary sends; 101-120 for generated
* "confirmed" -- over 6/120 confirmations
* "expired" -- for ordinary sends that have timed out without getting into a
block, or had its inputs otherwise respent
This change is proposed to fix webservices being ignorant of generated
transactions by keeping a standard category/format for all similar types of
entries.
Thoughts?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] [RFC] listtransactions reformatting
2011-07-16 17:14 [Bitcoin-development] [RFC] listtransactions reformatting Luke-Jr
@ 2011-07-16 19:59 ` Stéphane Gimenez
2011-07-16 20:03 ` Luke-Jr
0 siblings, 1 reply; 5+ messages in thread
From: Stéphane Gimenez @ 2011-07-16 19:59 UTC (permalink / raw)
To: Bitcoin Dev
Hi,
You may have a look at the following proposal. It associates
generations txouts with the appropriate addresses and accounts.
(See my previous mail)
https://github.com/sgimenez/bitcoin/commit/a8e6510042f2f7f951414c7da124668b30da4acd
> * Additions to your wallet always are category:"receive", no matter
> what kind of transaction
Either this, or maybe webservices should be told to forget about
categories and to rely only on the sign of the amounts. Maybe a "type"
field with values "credit"/"debit" could help them? This way, more
categories could be added later (escrow transactions, or other scripts
that might be standardized).
An official API guide (not just a technical reference) would be very
valuable here.
Last, I agree that {list,get}receivedby* should include generated
amounts, because there is currently no way to do this for
generations. (This issue is not addressed by my patch yet)
Best,
Stéphane
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] [RFC] listtransactions reformatting
2011-07-16 19:59 ` Stéphane Gimenez
@ 2011-07-16 20:03 ` Luke-Jr
2011-07-17 3:02 ` Gavin Andresen
0 siblings, 1 reply; 5+ messages in thread
From: Luke-Jr @ 2011-07-16 20:03 UTC (permalink / raw)
To: Stéphane Gimenez; +Cc: bitcoin-development
On Saturday, July 16, 2011 3:59:07 PM Stéphane Gimenez wrote:
> Hi,
>
> You may have a look at the following proposal. It associates
> generations txouts with the appropriate addresses and accounts.
> (See my previous mail)
>
> https://github.com/sgimenez/bitcoin/commit/a8e6510042f2f7f951414c7da124668b
> 30da4acd
It is also very broken, which is why I took the time to come up with something
workable when I needed it ;)
> > * Additions to your wallet always are category:"receive", no matter
> > what kind of transaction
>
> Either this, or maybe webservices should be told to forget about
> categories and to rely only on the sign of the amounts. Maybe a "type"
> field with values "credit"/"debit" could help them? This way, more
> categories could be added later (escrow transactions, or other scripts
> that might be standardized).
"move" is positive amount, but doesn't change the actual value in the wallet.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] [RFC] listtransactions reformatting
2011-07-16 20:03 ` Luke-Jr
@ 2011-07-17 3:02 ` Gavin Andresen
2011-07-17 11:53 ` Amir Taaki
0 siblings, 1 reply; 5+ messages in thread
From: Gavin Andresen @ 2011-07-17 3:02 UTC (permalink / raw)
To: bitcoin-development
Fixing listtransactions (and listreceivedby/etc) so coin generation
transactions to particular addresses/accounts are credited to that
address/account is a good idea.
I don't think changing listtransactions output would be on the
priority list for any web services operators (in fact, I think most
would scream bloody murder if the output changed in a way that forced
them to change their code). The accounts-related things that I think
ARE on their high-priority list are:
1) Fixing getbalance and listtransactions performance problems when
you have hundreds of thousands of transactions and thousands of
accounts.
2) push-notification of coins received to accounts, so they don't have
to poll for changes.
--
--
Gavin Andresen
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] [RFC] listtransactions reformatting
2011-07-17 3:02 ` Gavin Andresen
@ 2011-07-17 11:53 ` Amir Taaki
0 siblings, 0 replies; 5+ messages in thread
From: Amir Taaki @ 2011-07-17 11:53 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]
Oops, sorry Gavin. Meant to reply to the mailing list.
---------------
People should not be using accounts for receiving funds on
merchant sites. There are too many bugs associated with it, and it has
innumerable problems. Like not being able to merge wallets or lack of
find grained control when moving funds around.
https://gitorious.org/intersango/bitcoind/commit/50a6ab79ed8c5398648c52fbdc4be07f70dedadb
This is the recommended & most safest way to receive funds on a merchant site ATM.
listreceivedsince <timest> is called every so often by a cron job.
The output is parsed and placed into another table and then another job
will go and create a deposit request from that table. The next call to listreceivedsince <timest> will call with the time of the last
transaction, and doubles must be discarded using the txid.
Polling listtransactions is less convenient since you always repeat old
transactions that you may not need, get generated transactions and have
to pick a good number that goes back far enough, but not too far.
________________________________
From: Gavin Andresen <gavinandresen@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Sent: Sunday, July 17, 2011 5:02 AM
Subject: Re: [Bitcoin-development] [RFC] listtransactions reformatting
Fixing listtransactions (and listreceivedby/etc) so coin generation
transactions to particular addresses/accounts are credited to that
address/account is a good idea.
I don't think changing listtransactions output would be on the
priority list for any web services operators (in fact, I think most
would scream bloody murder if the output changed in a way that forced
them to change their code). The accounts-related things that I think
ARE on their high-priority list are:
1) Fixing getbalance and listtransactions performance problems when
you have hundreds of thousands of transactions and thousands of
accounts.
2) push-notification of coins received to accounts, so they don't have
to poll for changes.
--
--
Gavin Andresen
------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 3866 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-07-17 11:53 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-16 17:14 [Bitcoin-development] [RFC] listtransactions reformatting Luke-Jr
2011-07-16 19:59 ` Stéphane Gimenez
2011-07-16 20:03 ` Luke-Jr
2011-07-17 3:02 ` Gavin Andresen
2011-07-17 11:53 ` Amir Taaki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox