Bitcointalk · JSON-RPC programming tips using labels

中本聪,2010 年 5 月 26 日

SN-0664 已核对来源,附原文与上下文。

阅读语言
中文译文

我加了几个与标签相关的函数,帮助管理每个用户的多个地址。新增或更名的函数: getreceivedbyaddress -- 单个地址收到的金额 getreceivedbylabel -- 带此标签的所有地址收到的金额 listreceivedbyaddress -- 列出地址及其收到的金额 listreceivedbylabel -- 列出标签及其收到的金额 setlabel -- 为完整性补充的其他标签函数 getlabel getaddressesbylabel

为保持一致,我把 getamountreceived 更名为 getreceivedbyaddress、getallreceived 更名为 listreceivedbyaddress。旧名字仍在,以免破坏现有代码,但已弃用。

思路是:只要你在调用 getnewaddress 时提供用户名,就能用 "bylabel" 函数取得该用户在所有地址上的收款总额。你可以随意更换他的地址,不必操心追踪他所有旧地址。

自动更换用户收款地址的好办法:就在显示他当前地址之前,检查它是否收到过任何东西,如果有就换成新地址:

// Get a new address whenever the current one has received anything if (strAddr == "" || getreceivedbyaddress(strAddr) > 0) strAddr = getnewaddress(strUsername); // Label the address with username Display(strAddr); // Display their current receiving address

// Get total received by all the user's addresses getreceivedbylabel(strUsername, 0) // unconfirmed getreceivedbylabel(strUsername, 1) // available balance

如果只是取某个特定用户的余额,比如响应那个用户的页面请求,用 getreceivedbylabel;如果要遍历所有用户,最好用 listreceivedbylabel 拿到完整列表再对照结果扫描。用 getreceivedbylabel 扫描用户是 n 的平方,用 listreceivedbylabel 是 n-log-n(或 n 线性)。

其实只有当你为了"一收到钱就自发采取行动"而轮询、而不是用户打开网页看到余额后告诉你怎么处理时,才真正需要扫描全部用户。没必要轮询得太频繁。如果你要求 1 个确认,反正平均要 10 分钟,每几分钟轮询一次以上毫无意义。

如果你卖的是数字商品和服务——有人免费蹭到也没多大损失、也无法转卖牟利——我认为接受 0 确认没问题。

基本上只有卖黄金或货币时才需要多个确认。

ORIGINAL · 英文原文
I added label related functions to help with managing multiple addresses per user.  New or renamed functions are:
 getreceivedbyaddress -- amount received on a single address
 getreceivedbylabel -- amount received by all addresses with this label
 listreceivedbyaddress -- list addresses and amounts they've received
 listreceivedbylabel -- list labels and amounts they've received
 setlabel -- misc label functions for completeness
 getlabel
 getaddressesbylabel

For consistency I renamed getamountreceived->getreceivedbyaddress and getallreceived->listreceivedbyaddress.  The old names are still there so as not to break existing code, but they're deprecated.

The idea is that if you give the username whenever you call getnewaddress, you can get the user's total received across all their addresses using the "bylabel" functions.  You can freely change their address without worrying about tracking all their old addresses.

A good way to automate changing the user's receiving address: just before displaying their current address, check if it has been used to receive anything, if it has then replace it with a new one:

// Get a new address whenever the current one has received anything
if (strAddr == "" || getreceivedbyaddress(strAddr) > 0)
   strAddr = getnewaddress(strUsername); // Label the address with username
Display(strAddr); // Display their current receiving address

// Get total received by all the user's addresses
getreceivedbylabel(strUsername, 0) // unconfirmed
getreceivedbylabel(strUsername, 1) // available balance

If you're just getting one particular user's balance, such as in response to a page request by that user, use getreceivedbylabel, but if you're scanning over all users, it's better to use listreceivedbylabel to get the complete list and scan against the result.  Scanning users with getreceivedbylabel would be n-squared, using listreceivedbylabel is n-log-n (or n linear).

You should only really need to scan all users if you're polling in order to spontaneously take action in response to money received, rather than the user going to a webpage, seeing their balance and telling you what to do with it.  It's not necessary to poll very frequently.  If you require 1 confirmation, that'll take an average of 10 minutes anyway, so there's no point in polling more often than every few minutes.

If you're selling digital goods and services, where you don't lose much if someone gets a free access, and it can't be resold for profit, I think you're fine to accept 0 confirmations.

It's mostly only if you were selling gold or currency that you'd need multiple confirmations.
上下文
← 上一条 SN-0664 · 当前 下一条 → 在档案中查看完整主题串 →
来源
Bitcointalk 原始链接 ↗ 记录编号 SN-0664