are you trying this on namecoin.exe or "namecoin.exe - testnet" ?
i got no idea of code but i can sure test gui's,
if someone can send me some nmc's testnet in my direction i can try reproduce the bug.
myTH1TgaSsJ2SsVpwTjXMaKKEzuoWahEB9
maybe create a thread where people can test this, receive nmc testnets and links to latest binaries and qt download.
i assume nmc testnet will be forked soon? make sure to say if present .exe should be used in real or testnet.
nmc regular blockchain downloads fine in my ssd laptop, nmc testnet is super-slow.
I'm not sure if you mean the bug I'm reporting or just generic testing, but if the former you'll not be able to test using the GUI as there's no means to controlling the change address there. |
|
|
|
it's ok with fresh wallet it seems.. maybe it's something to do with your wallet.. looking again though
All addresses in this wallet are without privkey (from importaddress), so maybe that's one problem. On the other hand, even using only imported addresses without priv keys this works perfectly if I send from one address to two others (i.e. no address reuse). I will try with a fresh wallet and importaddress, and if that still fails I'll try a fresh wallet and importprivkey. |
|
|
|
Bounty #2:
Based on snailbrain's latest namecoin-qt I have the following problem:
- manually create and submit a tx to send full balance of addr1
-> part to addr2
-> part back to addr1 (think change back to sending address)
- The transaction is sent correctly but the wallet is updated only for the debit of addr1 and credit of addr2. For some reason the credit of addr1 is ignored, even when the the tx is included in a block
- restarting namecoind with -rescan gets that balance back
I need the above to work as in bitcoin, i.e. when sending to the address the output belongs to, both debit and credit to that address get processed by the wallet.
I have 1 BTC up for grabs for that fix, and I'll also try to fix it myself time permitting.
Yesterday I asked for pointers on #bitcoin-dev and instead of tech advice I got a "you shouldn't do that"... oh well.
maybe try the update.. testing "seemed" to show the correct amounts? I have just tried again updated to commit 8166101ae213932a3f1aa095514eb682b3afb10e, and the behaviour still exists. $ namecoind getrawtransaction 9846d830e40493c0c72147e959a66d2769589d69dd3d05946868f1a48649fd9e 1
{
"hex" : "0100000001806b08da2f9175701c49a17492756030d1dc23d12f6c55f3a1c4dd53965fc6d1010000008c493046022100dc04b4e883bb15e46743c1298998223174fa73a175a1b4b461a366767282acf2022100ae2a7be906546f11a27f4d111e63aa585d0d7298a38c4de8ee07360aec13589d0141043cadb089ec6f22fafe75e859b593dc6ef9d896a2960254f847c1ab9009b9e9880e4ef55db17d7f17bdaeb523c7290e34f4c5e8779147b5d236562f794ab0426dffffffff0200943577000000001976a9146f577163208cbc1b624d248bc768bcdb49e0dce688ac00ca9a3b000000001976a914bc744a8542b08214d604efefafc5cf743e369c8c88ac00000000",
"txid" : "9846d830e40493c0c72147e959a66d2769589d69dd3d05946868f1a48649fd9e",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "d1c65f9653ddc4a1f3556c2fd123dcd13060759274a1491c7075912fda086b80",
"vout" : 1,
"scriptSig" : {
"asm" : "3046022100dc04b4e883bb15e46743c1298998223174fa73a175a1b4b461a366767282acf2022100ae2a7be906546f11a27f4d111e63aa585d0d7298a38c4de8ee07360aec13589d01 043cadb089ec6f22fafe75e859b593dc6ef9d896a2960254f847c1ab9009b9e9880e4ef55db17d7f17bdaeb523c7290e34f4c5e8779147b5d236562f794ab0426d",
"hex" : "493046022100dc04b4e883bb15e46743c1298998223174fa73a175a1b4b461a366767282acf2022100ae2a7be906546f11a27f4d111e63aa585d0d7298a38c4de8ee07360aec13589d0141043cadb089ec6f22fafe75e859b593dc6ef9d896a2960254f847c1ab9009b9e9880e4ef55db17d7f17bdaeb523c7290e34f4c5e8779147b5d236562f794ab0426d"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 20.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 6f577163208cbc1b624d248bc768bcdb49e0dce6 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9146f577163208cbc1b624d248bc768bcdb49e0dce688ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"N6j5xaeunEBQmDtZ5XzXH8TyWaqMWKdmFz"
]
}
},
{
"value" : 10.00000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 bc744a8542b08214d604efefafc5cf743e369c8c OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914bc744a8542b08214d604efefafc5cf743e369c8c88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"NDkpYkwmfPeS5hTqiSm2E4YQp1XrEu8j4y"
]
}
}
],
"blockhash" : "4545e816172b83a89fffc93c691f1ec4c48a0b4f1549b2e05b2a2149dbc33ce5",
"confirmations" : 1,
"time" : 1371119317,
"blocktime" : 1371119317
}
$ namecoind listunspent 0 9999999 '["N6j5xaeunEBQmDtZ5XzXH8TyWaqMWKdmFz"]'
[
{
"txid" : "9846d830e40493c0c72147e959a66d2769589d69dd3d05946868f1a48649fd9e",
"vout" : 0,
"scriptPubKey" : "76a9146f577163208cbc1b624d248bc768bcdb49e0dce688ac",
"amount" : 20.00000000,
"confirmations" : 1
}
]
$ namecoind listunspent 0 9999999 '["NDkpYkwmfPeS5hTqiSm2E4YQp1XrEu8j4y"]'
[
]
$ namecoind listaddressgroupings
[
[
[
"N6j5xaeunEBQmDtZ5XzXH8TyWaqMWKdmFz",
20.00000000,
"\"\""
],
[
"NAoLHrukBrGH8NbSMyL9sw4kBAyDN2s31L",
0.00000000,
""
],
]
]
|
|
|
|
|
I'll be contacting each of the buyers individually now. I just realized I forgot to make any mentions to warranties: during the first 15 days after you receive the boards, if you find any that is faulty send it back to me. After I check the board and if I find it faulty and don't see any obvious misuse (you'd be surprised) I will either send another board back if I have one or return the board's price.
The order according to my sorting is:
--pm--: 3 @ 1.5 (no reply)
tmackay: 20 @ 0.81 (escrow, paid) RECEIVED
woodrake: 80 @ 0.8 (escrow. paid) RECEIVED
--pm--: 50 @ 0.8 (escrow) RECEIVED
poochone: 10 @ 0.8 (no reply)
ZoladkowaGorzka: 3 @ 0.8 (paid) RECEIVED
az12: 3 @ 0.8 (cancelled)
--pm--: 3 @ 0.8 (dup, actually az12 above)
|
|
|
|
I'll Take 3 @ 0.8 if not too late .....
Well, it is and it isn't. I may still grab any offers made after the end date, obviously, but I'll work that out after the other ones are done with. |
|
|
|
|
I have updated the second post with all offers on the table. Give me a few hours to regroup here and I'll contact everyone to get these deals done.
|
|
|
|
Isn't there a way to fix that without reusing an address?
Huh? The problem only exists when reusing the address. My workflow depends on that, and changing the workflow is a lot of work. At any rate, this issue is a bug and should be fixed. |
|
|
|
Why wouldn't they recommend that?
Because reusing addresses hurts everyone's privacy... it's true to some extent, but it is always a problem when human behavior is the thing being hacked on instead of code. |
|
|
|
|
Just a quick bump, ~28 hours to go.
|
|
|
|
|
Bounty #2:
Based on snailbrain's latest namecoin-qt I have the following problem:
- manually create and submit a tx to send full balance of addr1
-> part to addr2
-> part back to addr1 (think change back to sending address)
- The transaction is sent correctly but the wallet is updated only for the debit of addr1 and credit of addr2. For some reason the credit of addr1 is ignored, even when the the tx is included in a block
- restarting namecoind with -rescan gets that balance back
I need the above to work as in bitcoin, i.e. when sending to the address the output belongs to, both debit and credit to that address get processed by the wallet.
I have 1 BTC up for grabs for that fix, and I'll also try to fix it myself time permitting.
Yesterday I asked for pointers on #bitcoin-dev and instead of tech advice I got a "you shouldn't do that"... oh well.
|
|
|
|
Oh well, it wasn't just a heads up, I was actually hoping you would also ship to EU...  |
|
|
|
|
Is that shipping included worldwide?
|
|
|
|
nelisky : so I just wanted to check that you're satisfied that your requirements have been fulfilled and tested for the namecoin-qt client, extra functions, open source, no hidden code, etc? If so I've agreed to put 500 nmc for namecoin-qt client code to get in to this state which I will happily pay. Also I have another 250nmc for this namecoin-qt to get merged back into official namecoin/namecoin github repository and another 250 nmc for it to rebased on top of the v0.8.2 bitcoin-namecoin compatability (i.e. leveldb, etc) mods that khal is currently working on. Thanks for all your work so far snailbrain, this is excellent I'm still not 100% sure there's nothing broken, but all the commands implemented work as advertised and I couldn't find any obvious "hidden code". This is no guarantee however, and before I get this into a production environment I'll do a full code review for my own benefit. |
|
|
|
<3 MzkyUxTvvQzzBaBwxGeGSosSmUF1Ctk34i
much appreciated
Bounty paid, tx c9dd9f1074b40c049ebc53c804377e1200201792dd6473a002a0059712eff98d |
|
|
|
|
Been testing snailbrain version with all the RPC commands added. So far everything is working pretty well, there's just one small issue which I'm not sure relates to snailbrain's updates or not, but is kind of problematic for me.
Regardless, I'm calling the 1000 NMC bounty I offered as fulfilled. Can you provide an address for sending it, snailbrain?
Now, the problem I'm having is (using addresses imported without private key, not sure if that's relevant) when sending a transaction that has the same address in inputs and outputs, for example returning change to the sending address. When I do that the sending address is empty as far as the daemon is concerned even though the transaction is properly formed. The only way to see the unspent output again is by rescanning.
Addr1 10 NMC
-> Addr2 9 NMC
-> Addr1 1 NMC
Addr2 has 9 NMC, Addr1 is empty until I restart with -rescan
Addr1 10 NMC
-> Addr2 9 NMC
-> Addr3 1 NMC
Addr1 is empty, Addr2 has 9 NMC, Addr3 has 1 NMC as expected.
|
|
|
|
|
All, at the current offer level I come to the conclusion that I'm better off keeping the boards, and when they become unprofitable sell them for the FPGAs.
I'll also not be around Tuesday/Wednesday so I won't be able to ship things as urgently as I wanted.
As such I will make one final call for offers, with a slightly different set of rules:
- Minimum offer of 0.8 BTC per card
- Offers will be sorted by price descending follow by quantity descending, in other words the higher price wins, and for the same price the larger quantity. All being the same, the order of offer (for thread offers, PMs go down on the priority list).
- Cables for direct connection to PSUs and metal spacers are offered on batches of 30+
- You pay shipping (after I ship, so we know exactly how much that was)
- This offer ends Wednesday June 12 @ 13:00 GMT. I will keep any boards not sold at that point.
- I will ship everything no later than Monday 17 assuming prompt payment (to escrow).
|
|
|
|
Do you have photos? what is the power draw?
I don't have photos of the specific boards, and won't be able to take any for a few days. I do have some which I sold separately at https://bitcointalk.org/index.php?topic=160693.msg1710727#msg1710727, but this particular offer is only for the boards, no 120mm fans, cables or spacers. I might be convinced to send the cables and spacers for bulk orders if the price justifies it. Each board takes ~11W @ 12V |
|
|
|
With such things time is of the essence, so let's up the stakes a little. I have 45 cleared BTC in my wallet right now (more is not a problem but will require a bank transfer - normally takes a couple of days) and I would like to purchase at least some of your stock soon. Would you be willing to sell me 60 at 0.70 BTC each (42 BTC total) with dispatch soon?
Please understand that is something of a limited time office. I've jumped up in price in hopes that you'll be willing to do a deal today with a view to shipping them early next week.
Kate.
I understand the urgency and appreciate the new offer. I am setting a flexible deadline on myself to decide on this, Monday, so unless I get an offer I can't refuse I'll stick to that. I fully understand you may wish to cancel your offer but since nothing will be shipped before Tuesday regardless of how quickly we close a deal, it will not make a difference in the end. |
|
|
|
It would be helpful to get a guide on what you feel is a reasonable price so that I can make a more sensible offer.
Well, Kate, that's not an easy thing for me to calculate, hence the open offer. I know all about the expected profitability I have, and while my cristal ball has been out of order for a while I have my personal sentiments as to what the BTC economy will do in the near future. I asked for offers in BTC because that's what the boards mine (disregarding the alt coins). I would also entertain offers in cash but that makes little sense as the ROI will be in BTC anyway. The broken cards are probably best fit for someone wanting to grab the FPGAs without shelling out €180 a piece, of course, but for using the boards for mining I expect them to make me more than 0.5 BTC in the next 4 months (electricity included). Granted, if diff keeps jumping like this last time I may be completely off, its a bet I guess. I may sell the boards for the offers already standing, don't get me wrong, I just meant I'm not closing the deal in a rush for that offer. It's still a completely valid offer. |
|
|
|
|
What about normal transfer fees (not name related), what's the schedule there? I'm feeling too lazy to go through the code, unforgivable I know, but it is Friday...
|
|
|
|
|
Show Posts
