JonSnow
Member
Offline
Activity: 112
Merit: 10
|
|
April 03, 2013, 10:37:04 PM |
|
Do you happen to know what happens when btc is sent to an expired "Shared Send" address? My bitcoin supplier sent a large amount without confirming the btc address with me, and ended up sending it to an expired "Shared Send" address of mine ... so now he's threatening my life and I'd really like to hear from Ben/piuk about that. lol. Annnnnddddddd stress level 1000000!
Piuk reads this thread so this is probably the best way to get in contact with him. Are the transactions confirmed on the expired address - or are they not confirming? If the latter, I would just wait for them to confirm, I've recently had some tx that take a day to confirm, even with a fee... the network is just very overloaded at the moment. Will The transaction that was sent to one of my "Shared Send" expired addresses now has over 100 confirmations. It's for $20k. The other unconfirmed transactions I would wait for, but they are transactions sent out to clients who bought the btc from us, and who are now also joining in on being pissed.
|
|
|
|
willphase
|
|
April 03, 2013, 10:40:47 PM |
|
The transaction that was sent to one of my "Shared Send" expired addresses now has over 100 confirmations. It's for $20k. The other unconfirmed transactions I would wait for, but they are transactions sent out to clients who bought the btc from us, and who are now also joining in on being pissed. so just to be clear - the transaction to your (expired) shared address has confirmed. Have the transactions come through to your masked address? Are those transactions confirmed? Please describe the situation exactly. is it 1. Transactions confirmed on shared address, no sign of any other transactions at all 2. Transactions confirmed on shared address, transactions have appeared on masked address but not confirming Will
|
|
|
|
JonSnow
Member
Offline
Activity: 112
Merit: 10
|
|
April 03, 2013, 10:43:00 PM |
|
1. Transactions confirmed on shared address, no sign of any other transactions at all ---- https://blockchain.info/tx/60d4d193d887687e1ac64d53e0734c1365996edeabecab82cb538e183dd1d3c3Basically, it was a Shared Send alias that was used on March 30th ... then the person didn't check with me before sending, and simply sent again to that same Shared Send alias. The Shared Send alias is no longer pushing to my wallet since they are single-use aliases or something. :*(
|
|
|
|
willphase
|
|
April 03, 2013, 10:49:17 PM |
|
1. Transactions confirmed on shared address, no sign of any other transactions at all
ah yes - in which case you do need to contact Ben and I'm sure he'll find the private keys for the shared address and forward them to you. He is on UTC+1 so he might be about to go to bed (approaching midnight) Will
|
|
|
|
piuk (OP)
|
|
April 04, 2013, 01:22:21 AM |
|
well, he was just logged in for awhile and now he's gone again. still no word re: the in limbo $20k.
Should be sorted now. ----- The unconfirmed transactions problem is not blockchain specific, confirmations are just slow at the moment becuase of increased transaction volume. In [Account Settings] the fee policy can be set to generous if you would prefer a feee was included every transaction.
|
|
|
|
Vink
Member
Offline
Activity: 116
Merit: 10
|
|
April 04, 2013, 05:54:15 AM |
|
What happened to the satoshi dice balance that shows how much you won/loss?
|
|
|
|
piuk (OP)
|
|
April 04, 2013, 06:55:05 PM Last edit: April 04, 2013, 07:15:31 PM by piuk |
|
My settings have always been on "generous" so not sure why two went out with 0 fee, but they did start moving so it's all okay.
Was the transaction made using one of the mobile apps? What happened to the satoshi dice balance that shows how much you won/loss?
Disabled due to high load. The way it is currently programmed is not efficient, it needs to check all soatoshidice bets ever made (which is now several million). ---- Site being ddos again. Had to enable cloudflare, any problems clear your DNS cache.
|
|
|
|
Scott J
Legendary
Offline
Activity: 1792
Merit: 1000
|
|
April 04, 2013, 09:57:31 PM |
|
This may be a stupid question, but why doesn't there seem to be an option to add a fee with the Android app?
|
|
|
|
chrisrico
|
|
April 04, 2013, 10:56:39 PM |
|
This may be a stupid question, but why doesn't there seem to be an option to add a fee with the Android app?
I believe it automatically determines if a fee is necessary. Just today I sent a transaction and it said a 0.005 fee was required. I hit cancel to change the amount sent (because I didn't have enough to include the fee) and it sent it without a fee. Now the transaction is sitting out there unconfirmed, my local buyer didn't see the transaction appear in Bitcoin-Qt, and is worried he won't get his money. Needless to say I won't be using the BlockChain Android app anymore...
|
|
|
|
JonSnow
Member
Offline
Activity: 112
Merit: 10
|
|
April 04, 2013, 11:09:41 PM |
|
My settings have always been on "generous" so not sure why two went out with 0 fee, but they did start moving so it's all okay.
Was the transaction made using one of the mobile apps? Yes, there were two made that way yesterday via the iPhone app. I've never had a problem with it before yesterday.
|
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3514
Merit: 4895
|
|
April 05, 2013, 05:06:50 PM |
|
Is it really such a low priority that it hasn't been included in more than 100 blocks,
I suspect it is the 0.00072335 BTC output that is causing you a problem. In general transactions with outputs less than 0.01 BTC aren't well relayed unless they include a fee of at least 0.0005 BTC. As such, many miners are probably not going to get to it until/unless we get to a point where there are no higher priority transactions waiting for a confirmation.
|
|
|
|
chrisrico
|
|
April 05, 2013, 05:37:24 PM |
|
Is it really such a low priority that it hasn't been included in more than 100 blocks,
I suspect it is the 0.00072335 BTC output that is causing you a problem. In general transactions with outputs less than 0.01 BTC aren't well relayed unless they include a fee of at least 0.0005 BTC. As such, many miners are probably not going to get to it until/unless we get to a point where there are no higher priority transactions waiting for a confirmation. That should matter, that's just the change output, the other is for 6.2 BTC.
|
|
|
|
giszmo
Legendary
Offline
Activity: 1862
Merit: 1114
WalletScrutiny.com
|
|
April 05, 2013, 08:04:26 PM |
|
Is it really such a low priority that it hasn't been included in more than 100 blocks,
I suspect it is the 0.00072335 BTC output that is causing you a problem. In general transactions with outputs less than 0.01 BTC aren't well relayed unless they include a fee of at least 0.0005 BTC. As such, many miners are probably not going to get to it until/unless we get to a point where there are no higher priority transactions waiting for a confirmation. That should matter, that's just the change output, the other is for 6.2 BTC. how can the miner know?
|
ɃɃWalletScrutiny.com | Is your wallet secure?(Methodology) WalletScrutiny checks if wallet builds are reproducible, a precondition for code audits to be of value. | ɃɃ |
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3514
Merit: 4895
|
|
April 05, 2013, 08:06:49 PM |
|
That should matter, that's just the change output, the other is for 6.2 BTC.
Bitcoin doesn't recognize a difference between "change" output or "transfer" output. An output is an output. Only you and your wallet know that it is "change".
|
|
|
|
chrisrico
|
|
April 05, 2013, 08:25:31 PM |
|
That should matter, that's just the change output, the other is for 6.2 BTC.
Bitcoin doesn't recognize a difference between "change" output or "transfer" output. An output is an output. Only you and your wallet know that it is "change". I understand this and shouldn't have even brought up the change issue. But since when does bitcoin prioritize based on individual output amounts instead of entire transaction amounts? As in, why would it ignore the 6.2 BTC output when determining that the other one is "too small"? I don't think that's how it works. From the Wiki: priority = sum(input_value_in_base_units * input_age)/size_in_bytes Given that the larger input was very recently confirmed, it makes sense that the transaction is a low priority. But not being included in a block for over a day seems out of the ordinary. Granted, I always pay transaction fees. With the obvious exception of this time, since Blockchain's Android app wanted me to pay 0.005, so I hit cancel, and then it sent the transaction without a fee.
|
|
|
|
nimda
|
|
April 06, 2013, 01:41:50 AM |
|
From the Wiki: priority = sum(input_value_in_base_units * input_age)/size_in_bytes Given that the larger input was very recently confirmed, it makes sense that the transaction is a low priority. But not being included in a block for over a day seems out of the ordinary. Granted, I always pay transaction fees. With the obvious exception of this time, since Blockchain's Android app wanted me to pay 0.005, so I hit cancel, and then it sent the transaction without a fee. Also from the Wiki: A transaction will be sent without fees if these conditions are met: - It is smaller than 10 thousand bytes.
- All outputs are 0.01 BTC or larger.
- Its priority is large enough (see the Technical Info section below)
|
|
|
|
chrisrico
|
|
April 06, 2013, 04:06:47 AM |
|
Also from the Wiki: A transaction will be sent without fees if these conditions are met: - It is smaller than 10 thousand bytes.
- All outputs are 0.01 BTC or larger.
- Its priority is large enough (see the Technical Info section below)
There is also this: Its priority is large enough, but since the 6 BTC input was only 1 block old, I don't think the priority was large enough. So it looks like this transaction was never relayed and will never be included in a block. If this was my own wallet, I would remove the transaction manually and create another one with a fee. Since it's a blockchain wallet, what can be done about this?
|
|
|
|
Newar
Legendary
Offline
Activity: 1358
Merit: 1001
https://gliph.me/hUF
|
|
April 06, 2013, 05:45:07 AM Last edit: April 06, 2013, 05:59:20 AM by Newar |
|
Also from the Wiki: A transaction will be sent without fees if these conditions are met: - It is smaller than 10 thousand bytes.
- All outputs are 0.01 BTC or larger.
- Its priority is large enough (see the Technical Info section below)
There is also this: Its priority is large enough, but since the 6 BTC input was only 1 block old, I don't think the priority was large enough. So it looks like this transaction was never relayed and will never be included in a block. If this was my own wallet, I would remove the transaction manually and create another one with a fee. Since it's a blockchain wallet, what can be done about this? Import the private key in bitcoin-qt and then use pywallet to delete the tx. Edit: On second thought, I'm not sure that will work.
|
|
|
|
BRules
|
|
April 06, 2013, 06:24:57 AM |
|
Also from the Wiki: A transaction will be sent without fees if these conditions are met: - It is smaller than 10 thousand bytes.
- All outputs are 0.01 BTC or larger.
- Its priority is large enough (see the Technical Info section below)
There is also this: Its priority is large enough, but since the 6 BTC input was only 1 block old, I don't think the priority was large enough. So it looks like this transaction was never relayed and will never be included in a block. If this was my own wallet, I would remove the transaction manually and create another one with a fee. Since it's a blockchain wallet, what can be done about this? Import the private key in bitcoin-qt and then use pywallet to delete the tx. Edit: On second thought, I'm not sure that will work. it will work, I have almost the same problem: https://bitcointalk.org/index.php?topic=147519.0just imported the private keys to my bitcoin qt and I was able to create another transaction that confirmed without problems.
|
|
|
|
|