 Show Posts
|
|
Pages: [1] 2 3 4 »
|
|
2
|
Bitcoin / Development & Technical Discussion / Re: How does the Bitcoin Core v0.9.1-beta Coin Control - Custom change address work?
|
on: April 16, 2014, 12:40:23 AM
|
Using the "Custom change address" feature only works for addresses part of your wallet. Sending change to an address outside of your wallet is not supported currently. If you try this, a "Warning: Unknown change address" is shown and the change will be sent to a newly generated address. So in your case the wallet created a new change address and sent the change there. The reason is we supported this feature in earlier versions of coin control, but removed it for safety reasons. So people do not accidentally send all their coins as change to someone else. This is no bug, but I agree that the current behavior is a little confusing to the user. We should either - reject sending to a foreign change address - ask "Are you really really sure?" and then enable this feature again - or at least change the message to "Unknown change address -> change will be sent to a newly generated address" You can create an issue "Sending custom change to a foreign address in coin control is confusing" (or similar title) for this, if you like: https://github.com/bitcoin/bitcoin/issues |
|
|
|
|
4
|
Bitcoin / Development & Technical Discussion / Re: Yet another Coin Control Release
|
on: March 10, 2014, 10:56:54 PM
|
|
@subSTRATA
about 3)
I can confirm this on windows.
It should not affect coin control functionality, but the checkbox state is misleading currently.
My first thought is that this is related to going from qt4 to qt5, in any case I will look into this.
Edit: Just compiled under linux, yes this is a qt5 bug. I will try to submit this upstream somehow.
about 4)
This is expected. Addresses you create by yourself are not considered as change addresses by the
wallet. So they will not appear as child. This may not be what you expect in this case, but this problem
is rather related to the way the wallet recognizes change in general, than to coin control.
Edit: By the way if you prefer the old receive tab, its still available through menu->File->Receiving addresses
|
|
|
|
|
5
|
Bitcoin / Development & Technical Discussion / Re: Yet another Coin Control Release
|
on: December 25, 2013, 06:17:28 PM
|
|
What people can do, who can not code, but want to help with a GUI feature, is providing a complete prepared mockup.
Including:
- Screenshots, created with gimp,paint,
Or better: download QT Designer and click the GUI together
- Think the whole thing through, make a list of all features and use cases
Also things like: What should happen if...
- Icons, Pictures
- Helptexts, error-messages, tooltips, descriptions, labels
- write a testplan
This is all very simple but time consuming stuff. A developer who can just pick up from there, and does not have to think about what to implement
has a very easy job.
About the other thing:
You have to understand gavin and why he made such a drama with the testplan. This is not about a core dev having privileges over a community dev,
but a known dev over an unknown one. It was the first pull request I have submitted without any references, so there is nothing wrong in testing and code reviewing this
a little more, than from a developer who you know has delivered stable code for years.
|
|
|
|
|
9
|
Bitcoin / Development & Technical Discussion / Re: Yet another Coin Control Release
|
on: July 15, 2013, 11:01:00 PM
|
Before I dump my time into it... do you also have a hint on this one? g++ -Wl,--dynamicbase -Wl,--nxcompat -Wl,--large-address-aware -Wl,-s -mthreads -Wl,-subsystem,windows -o release/bitcoin-qt.exe object_script.bitcoin-qt.Release -L'c:/Qt/4.8.5/lib' -lmingwthrd -lmingw32 -lqtmain build/bitcoin-qt_res.o -Llibs/miniupnpc-1.8 -lminiupnpc -liphlpapi C:/_temp/_bitcoin_0.8.3_coincontrol/src/leveldb/libleveldb.a C:/_temp/_bitcoin_0.8.3_coincontrol/src/leveldb/libmemenv.a -lshlwapi -Llibs/boost_1_54_0/stage/lib -Llibs/db-4.8.30.NC/build_unix -Llibs/openssl-1.0.1e -lssl -lcrypto -ldb_cxx -lws2_32 -lshlwapi -lmswsock -lole32 -loleaut32 -luuid -lgdi32 -lboost_system-mgw46-mt-sd-1_54 -lboost_filesystem-mgw46-mt-sd-1_54 -lboost_program_options-mgw46-mt-sd-1_54 -lboost_thread-mgw46-mt-sd-1_54 -lboost_chrono-mgw46-mt-sd-1_54 -lQtGui4 -lQtNetwork4 -lQtCore4
./build/coincontroldialog.o:coincontroldialog.cpp:(.text+0x1cda): undefined reference to `WalletModel::listLockedCoins(std::vector<COutPoint, std::allocator<COutPoint> >&)'
./build/coincontroldialog.o:coincontroldialog.cpp:(.text+0x2077): undefined reference to `WalletModel::isLockedCoin(uint256, unsig ned int) const'
./build/coincontroldialog.o:coincontroldialog.cpp:(.text+0x2324): undefined reference to `WalletModel::unlockCoin(COutPoint&)'
./build/coincontroldialog.o:coincontroldialog.cpp:(.text+0x263e): undefined reference to `WalletModel::lockCoin(COutPoint&)'
...
looks like you are using the original bitcoin-qt.pro, not the new one. I have tested the code I gave you again, it sure compiles for me. |
|
|
|
|
13
|
Bitcoin / Project Development / Re: Implementing “Ultimate blockchain compression & trust-free lite nodes”
|
on: July 01, 2013, 10:25:54 PM
|
|
Does the UTXO root hash have to be recalculated after every block, and maybe other tree recalculations?
If so, I am a little bit concerned about the performance impact. Lets say bitcoin grows, then the recalculation of this thing could
take minutes.
So do you think, it is possible to do all the necessary recalculations after every block in lets say 1 second, even if bitcoin gets really big and there is huge database?
(other than this, many thanks for working on the project, I have donated 1BTC)
|
|
|
|
|
15
|
Bitcoin / Development & Technical Discussion / Re: Yet another Coin Control Release
|
on: June 12, 2013, 11:42:32 PM
|
Using cozz version for few days now, no bugs found whatsoever. One feature request though, it would be cool if numbers on right to "Amount"
and "Minus Fee" are selectable so that one just selects them and copy / paste to BTC amount field. It would make sending the exact "Minus Fee"
amount faster and easier (moving all selected inputs - fee to some address).
you can copy to clipboard. simply direct right click. |
|
|
|
|
16
|
Bitcoin / Development & Technical Discussion / Re: Yet another Coin Control Release
|
on: June 07, 2013, 07:47:33 AM
|
grue, cozz, what's the difference between your builds? cozz is smaller (probably compressed) and doesn't include the warning message. But otherwise, are they the same?
grues doesnt include the Updates to the new dust logic. Also grues is based on some development snapshot, while mine is based on the latest stable version 0.8.2. |
|
|
|
|
20
|
Bitcoin / Development & Technical Discussion / Re: Yet another Coin Control Release
|
on: March 17, 2013, 02:16:46 AM
|
|
UPDATE:
first of all, thank you to the 2 people who donated.
gmaxwell from the devs gave me some pointers, so I implemented them:
- removed send change "back to input", because this might confuse people
- address-label is shown, if you enter a change address, also warning if change address is not in wallet or invalid address
- you can now lock/unlock per right-click in the GUI (same as the new cli method "lockunspent")
- (un)select all is now a button to be easier recognizable
- confirmations is now a number, no more icons
- the calculation labels are now on top and also shown in send coins dialog (see screenshots)
- "priority" added (very low - very high): miners order transactions by priority when selecting which go into a block
priority = coinage / transactionsize
coinage = value * confirmations
- fee is now calculated for real (before it did not take min-fee into account)
In order to be able to send a free transaction, you need to follow the rules:
- transaction size must be < 10000 bytes
- priority must be at least "medium"
- any recipient must receive at least 0.01BTC
- change must be either zero or at least 0.01BTC
If you violate one rule you will see a min-fee and also the labels turn red:
Bytes.Priority,Low Output,Change. Depending which rule you violated.
Those 4 labels also have tool tips explaining this.
Also remember that violating one of the first 2 rules means 0.0005 PER kilobyte min-fee,
while violating one of the last 2 means 0.0005 min-fee only.
(Just for the record, I did not make those rules, if you dont like them complain to satoshi:)
|
|
|
|
|
