-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rpcclient: map[btcutil.Address]btcutil.Amount in sendmany is a pretty dangerous #999
Comments
From @jrick on January 18, 2017 17:40 Yeah, this is an issue because we set the pointers to the concrete address type as the Address interface value. If we put the non-pointer type in the interface I believe it will equate correct, since it will compare the actual struct values themselves instead of doing pointer equality. |
From @jrick on January 18, 2017 17:45 Sadly that's not possible since we are using pointer receivers, so the values themselves cannot satisfy the interface: https://play.golang.org/p/J7UWiO7x_o (change the pointer receiver to a non-pointer and notice how the commented out code now compiles, and evaluates to true.) |
From @jrick on January 18, 2017 17:55 We are still stuck with this data structure though since it has to encode to a json object for the bitcoin json-rpc api. In my mind it makes more sense to provide an (ordered) array of address+value objects to add as outputs for the transaction, but this would be incompatible with the existing api. |
From @FrozenPrincess on January 21, 2017 6:2 This seems like a pretty simple fix, no? The function is currently:
and just needs to be changed to:
|
From @jrick on January 21, 2017 16:54 I'm not happy with that either because two outputs both paying to the same address is not the same thing as a single payment of the combined amount. While the API here is pretty stupid, this is actually not technically a problem with the fact that bitcoin uses a JSON object keyed by addresses for representing these, as JSON does allow (but discourages) duplicate keys. It becomes a problem for us (and implementations in many other languages) that use a hashmap/btreemap/etc. for representation of the object. I also think the original issue was talking more about the general fact that map[btcutil.Address]foo is generally a bad idea, or that you must be very careful using them. But then again, it's no more dangerous than comparing btcutil.Address objects already, since that will also just do a memory address comparison. |
From @FrozenPrincess on January 21, 2017 17:6
Well, it's technically a problem in the sense it's currently not working. I just tested (against bitcoin core) with a
Is blasting away the previous entry. I'd also think it's acceptable to check the |
Greetings, I am getting this exact behaviour when I am trying to send to the same address two different times using SendMany(). The second entry and it's amount is getting overwritten
I read from above that this is a limitation of bitcoin due to that bitcoin uses a JSON object keyed by addresses for representing adresses, as JSON does allow (but discourages) duplicate keys and I understand this.
Best regards ! |
…dress is the same - please see my comment here - btcsuite/btcd#999 (comment)
From @glenherb on January 18, 2017 17:29
For example take this code:
There is a subtle problem that looking up in amounts will never work, because despite btcutil.Address being comparable, it's not a logic comparison. When it's finally sent over rpc, one of the payments can be silently be dropped
Copied from original issue: btcsuite/btcrpcclient#112
The text was updated successfully, but these errors were encountered: