0 Members and 1 Guest are viewing this topic.
Is there a fun game to be played if we don't come to an agreement?
This bounty has been completed. Can we have some confirmation please.
C:\ProtoShares>make -f Makefile.Releasecl -c -nologo -Zm200 -Zc:wchar_t- -O2 -MD -GR -EHsc -W3 -w34100 -w34189 -DUNICODE -DWIN32-DQT_DLL -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT -DNDEBUG -I"..\Qt\4.8.5\include\QtCore" -I"..\Qt\4.8.5\include\QtGui" -I"..\Qt\4.8.5\include" -I"." -I"..\Qt\4.8.5\include\ActiveQt" -I"release" -I"." -I"..\Qt\4.8.5\mkspecs\win32-msvc2010" -Forelease\ @<<<< was unexpected at this time.make: *** [{src\qt\test}.cpp{release\}.obj] Error 255Can't seem to get past this
/*if (nIndex != -1) vchPubKey = keypool.vchPubKey; else { if (pwallet->vchDefaultKey.IsValid()) { printf("CReserveKey::GetReservedKey(): Warning: Using default key instead of a new key, top up your keypool!");*/ vchPubKey = pwallet->vchDefaultKey; /*} else return false; }*/
Quote from: FreeTrade on January 05, 2014, 03:39:34 pmWhat are you trying to achieve with this? MemoryCoin always sends change to the default or first key in the wallet - quite a small code change to do that, but why the need to specify the key?I am surprised you do this with memory coin, it means that all of your transactions are linked and easily tracked.
What are you trying to achieve with this? MemoryCoin always sends change to the default or first key in the wallet - quite a small code change to do that, but why the need to specify the key?
static const unsigned int MAX_INV_SZ = 50000;
main.h:615:11: error: default argument missing for parameter 3 of ‘int64 CTransaction::GetMinFee(unsigned int, bool, unsigned int, GetMinFee_mode) const’
Quote from: donschoe on January 04, 2014, 08:01:05 pmThis is a huge change in the client and protocol how transactions are processed.I think this topic is worth ~ 500 PTS. A good approach would be to implement the experimental coin control from bitcoin client.Read more on "bitcoin coin control" on google.https://bitcointalk.org/index.php?topic=144331.0https://github.com/bitcoin/bitcoin/pull/2343It should just be replacing the change address and nothing on the protocol layer. I will up the bounty slightly.
This is a huge change in the client and protocol how transactions are processed.I think this topic is worth ~ 500 PTS. A good approach would be to implement the experimental coin control from bitcoin client.Read more on "bitcoin coin control" on google.https://bitcointalk.org/index.php?topic=144331.0https://github.com/bitcoin/bitcoin/pull/2343
What error do you get when you try to push?
Quote from: toast on January 04, 2014, 11:36:57 pmThat's really weird, are you sure you are working in your own ProtoShares fork and not the I3 one? Also try re-cloningtried re-cloning again but it's no use, i have tried all the available braches, but it refuses. I need to get a dedicated linux box next month, windows is just too complicated.
That's really weird, are you sure you are working in your own ProtoShares fork and not the I3 one? Also try re-cloning
Can you put it on github?Make an account, click "fork" on the I3 protoshares repo.Code: [Select]git clone <YOUR protoshares repo>## make your changesgit add -ugit commit -m "coincontrol"git push
git clone <YOUR protoshares repo>## make your changesgit add -ugit commit -m "coincontrol"git push
Not sure if this is a healthy attitude but if protoshareholders are supposed to have "the resources, the interest, and the domain knowledge to invest [protoshares] wisely", should we really be doing this much hand-holding?
clientversion.h compat.h core.h crypter.h db.h hash.h init.h \
clientversion.h coincontrol.h compat.h core.h crypter.h db.h hash.h init.h \
forms/askpassphrasedialog.ui forms/editaddressdialog.ui forms/intro.ui \
forms/askpassphrasedialog.ui forms/coincontroldialog.ui forms/editaddressdialog.ui forms/intro.ui \
// Note: We use a new key here to keep it from being obvious which side is the change. + // The drawback is that by not reusing a previous key, the change may be lost if a + // backup is restored, if the backup doesn't have the new private key for the change. + // If we reused the old key, it would be possible to add code to look for and + // rediscover unknown transactions that were written with keys of ours to recover + // post-backup change.
I had already started putting Coin Control, should i stop? I'm half way done.
Quote from: bytemaster on January 04, 2014, 08:03:13 pmIt should just be replacing the change address and nothing on the protocol layer. I will up the bounty slightly. So will there be separate clients for people that want the usual change behavior and people that want change to come back to the same address?(giving the user the option to choose is basically re-implementing coincontrol)
It should just be replacing the change address and nothing on the protocol layer. I will up the bounty slightly.