Search content
Sort by

Showing 20 of 75 results by evilpete
Post
Topic
Board Beginners & Help
Re: It has been over 24 hrs since I sant BTC Transaction still unconfiremd
by
evilpete
on 14/03/2014, 23:41:22 UTC
It's really important to read that wiki article as it spells out how blocks are filled out in the classic mining model.  Not every pool follows that policy, but it is safe to assume that many do something close to it.

Short version:
1) There is a fixed chunk of space reserved for high priority transactions (sorted by priority, fee is ignored)
2) the rest is reserved for fee paying transactions, in order of fee size.

No-fee transactions can only be processed by #1, and cannot be considered for #2.  You are competing with transactions of high priority old coins.

At this very moment there are a large number of high priority transactions in the memory pool.  Many will take up the entire space in a single block that's reserved for high priority transactions.  It could take days to catch up as more are being generated.  The only way "free" transactions get confirmed is when there is room in this high priority pool.

It'll get confirmed but it could be minutes, hours, days or even weeks.  There is no practical upper limit.  It's not worth the risk of going below the minimum fee.

If you include the proper fee, you'll be able to be included in the fee paying section of the block as well.  It'll take minutes that way.

1 satoshi is dust, not a fee. Use the proper forumula.
Post
Topic
Board Bitcoin Technical Support
Re: transaction disappeared from block chain??
by
evilpete
on 14/03/2014, 19:43:51 UTC
Hmm, again, from that wiki page:

Quote
Including in Blocks

This section describes how the reference implementation selects which transactions to put into new blocks, with default settings. All of the settings may be changed if a miner wants to create larger or smaller blocks containing more or fewer free transactions.

30,000 bytes in the block are set aside for the highest-priority transactions, regardless of transaction fee. Transactions are added highest-priority-first to this section of the block.

Then transactions that pay a fee of at least 0.0001 BTC/kb are added to the block, highest-fee transactions first, until the block is not more than 300,000 bytes big.

The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough.

I know, that is talking about the reference client's block construction behavior but it might explain a few things if it is a fair representation of what miners are doing.

A quick scan of my mempool of unconfirmed transactions and their priority, sorted by "highest priority":
Code:
22247 29510957894.26107407
22251 24617855466.11368179
22237 23797564629.60096359
22245 23794448299.07243729
27302 21127378315.33507919
22238 21059217907.33554459
22229 18540419334.94335556
22254 16502444715.59822273
22237 16130040247.36238289
22251 15074281814.33272171
22249 15068602923.64821625
22240 12768199194.55590630
5965 10029852114.08262253
7176 8947361947.19983292
2852 7769685225.87504864
22240 7673617191.58819962
4332 7591994500.56230640
5693 7554179627.29180527
22241 7394041900.16759014
9256 7123151255.12517929
5559 6836646125.44707775
259 6533343333.33333302
6436 6173324479.56040573
523 6033913454.75903320
1261 5822628219.26124096
16646 5444277224.78949356
258 5092818188.14678001
....
First column is bytes.  That's pretty much going to eat up the "30000 is reserved for highest priority" for quite some time.  You're currently ranked #171 from the top of that list.  There's 577781 bytes of "high priority" traffic ahead of yours.

Because your tx is fee free, it won't fit in the second group.

It is unclear how many pools use the transaction selection models that the reference client uses, or what quirks they have.

This is going to take a while.  Be extremely careful if you're thinking of resending, it could still confirm.
Post
Topic
Board Bitcoin Technical Support
Re: transaction disappeared from block chain??
by
evilpete
on 14/03/2014, 19:22:51 UTC
First of all, there are several key components in play here.

1) Your wallet.  It has an unconfirmed transaction in it.  Your bitcoin client will keep doing a ResendWalletTransactions() every so often to the P2P network until it is either confirmed by a miner, or you delete it from the wallet.

2) The P2P network.  Every bitcoin node keeps a list of unconfirmed transactions in memory (the MemPool) so that they can be relayed to other nodes.  They time out after a while - exactly how long depends on local factors, activity, node restarts etc.  When the nodes see transactions appear in blocks, they also get removed from the mempool.

3) Miners.  They take the highest priority transactions from the mempool and set them in stone in blocks.

Wallet clients normally resend the transaction periodically.

I poked around a bit.  *my* clients all know about the transaction of yours:

Code:
$ bitcoin-cli getrawtransaction "d2d79b1c5153c8e6c4dc007044b277b345a4867954cd8d9ec5d5b9f0675a0563" 1
...
    "vout" : [
        {
            "value" : 0.40000000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 0910bf8deaccae0abb0a201107ab57fccba85e3f OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9140910bf8deaccae0abb0a201107ab57fccba85e3f88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1pw9R8BCWdojic8bryNqaAXoh77D5tBeb"
                ]
            }
        },

It looks like you spent 5 outputs:
#1570 of 7bd8cecc8481baffbb545efc6f9949ccd2c3d87241ff6316c2d4fb975d055891 (0.109 btc 2071 confirm)
#836 of 330a32b6d7312ea2ad8b6b50cb6e418d251d73822aa3d48c979aea9f0544658f (0.161 2226 confirm)
#908 of ba8a17326f7f85ca27e2be8954d8da4ac8755486ce8f71b463f86da73c44b455 (0.021 btc 801 confirm)
#540 of 19c53d50895e35d1a0445c66dca1bef3cde39dd64603f1729a4db8c6dff6174b (0.024 btc 1762 confirm)
#2722 of d07d6c039b95484a634ea5d8e3e44da54aed8abcb8d313da92396a8e62e3a758 (0.093 btc 1327 confirm)

My quick dig around in the blockchain shows these as unspent.

However, on https://en.bitcoin.it/wiki/Transaction_fees it talks about transaction priority as a prerequisite for a fee-free transaction.  I'm pretty sure that is old information.
Code:
$ bitcoin-cli getrawmempool true
...
    "d2d79b1c5153c8e6c4dc007044b277b345a4867954cd8d9ec5d5b9f0675a0563" : {
        "size" : 819,
        "fee" : 0.00000000,
        "time" : 1394515894,
        "height" : 289982,
        "startingpriority" : 687882974.94871795,
        "currentpriority" : 716569858.93772888,
        "depends" : [
        ]
    },
.. so it should qualify for fee-free.  In my client's mempool, is ranked at priority 2014 of 2180.. right near the top.

Aside from the zero fee (which it is entitled to be, according to the rules), I'm not sure I see why this hasn't confirmed yet.

What am I missing?
Post
Topic
Board Bitcoin Technical Support
Re: [GUIDE] Delete your 0/unconfirmed transactions in 30 seconds
by
evilpete
on 14/03/2014, 07:41:26 UTC
New method with 0.9+ built directly into core client:

  -rescan                Rescan the block chain for missing wallet transactions
  -zapwallettxes         Clear list of wallet transactions (diagnostic tool; implies -rescan)

It does exactly what it says - it rebuilds the transaction list from the officially confirmed blocks.

Naturally, get a reliable wallet backup first.
Post
Topic
Board Bitcoin Technical Support
Re: transaction disappeared from block chain??
by
evilpete
on 14/03/2014, 07:34:51 UTC
The short version:  Your Wallet thinks the transaction has been spent. It'll try to re-broadcast it to the network periodically.

If you're using older bitcoin software, check out pywallet - you can delete the transaction and stop your client trying to re-send the transaction.  This will free up the 0.4 btc for respending.

If you are using 0.9rc2 or later, there are new options:

  -rescan                Rescan the block chain for missing wallet transactions
  -zapwallettxes         Clear list of wallet transactions (diagnostic tool; implies -rescan)

The latter discards the transaction record and rescans the wallet to find them again.  This gets rid of stuck / unconfirmed transactions that can't be confirmed.

Note: if the network has a copy of the transaction in the P2P network and its queued up at a miner, it could still be confirmed - in which case your client will notice and update the balances.

No matter what you do (pywallet or a 0.9 zap/rescan), a solid backup of your wallet would be in order.
Post
Topic
Board Development & Technical Discussion
Re: How 'Anonymous' is Bitcoin?
by
evilpete
on 24/02/2014, 20:49:02 UTC
bittyweb:  Bitcoin is only truly "anonymous" so long as you don't do anything with it.

In addition to what DannyHamilton said, suppose you buy bitcoins from your localbitcoins dealer.  Now imagine the Florida scenario where those bitcoin dealers were busted.  Now their records/wallets (and timestamps) are presumably in the hands of law enforcement.  The dealer may have been under surveillance when he sold to you.  You might be on the starbucks security camera where you met the dealer.  Maybe you bought a coffee at the starbucks with a credit card or are known to the staff.  etc etc.  Once "they" find some of your addresses and put some effort into taint analysis, things get interesting.

In reality, Bitcoin only gives you a degree of anonymity.  It gets you out of the scope of the NSA casually fishing through bank records to find likely names/addresses of people, but if somebody REALLY wants to find you, sooner or later, they will.  The more you interact with or trade with people, the more traces you leave.

In short, don't depend on bitcoin to keep you out of jail if you're breaking the law.  It isn't designed for that.  It is meant to keep you out of reach of "fishing expeditions", not a concerted law enforcement effort.
Post
Topic
Board Bitcoin Technical Support
Re: Bug in Bitcoin-QT v0.8.6-beta??
by
evilpete
on 02/01/2014, 23:24:57 UTC
What is the proper way to move my wallet to another computer or to MultiBit?
So if i just import my main wallet using privkey, what happens whitch my change wallet? It is will be lost?

If you import the privkey, you're losing the change addresses.  If you can import the entire wallet, that would get all the invisible change privkeys as well.

Or, just pay an address in your multibit wallet from your bitcoin-qt wallet.
Post
Topic
Board Bitcoin Technical Support
Re: Bug in Bitcoin-QT v0.8.6-beta??
by
evilpete
on 02/01/2014, 23:22:18 UTC
This is just the way bitcoin works.  You don't have an "account" with a balance like you do with a bank.  The wallet metaphor is more accurate.  Your wallet is a collection of individual payments and it adds up the total to show you a "balance".

Bitcoin is a journal of who paid what to whom.  Each payment is either "spent" or "not spent".  The wallets keep all the individual payments stored together.  When you pay an amount to somebody, the wallet software collects up "enough" individual amounts, and creates a transaction that pays somebody else an amount, and pays *you* the change.

Suppose you received 0.8btc and 0.6btc and want to pay somebody 1btc.  Your wallet will select the 0.8 and 0.6 inputs to spend, sending 1btc to the person and 0.4btc back to you as change.  The 0.8 and 0.6 are now gone, and you have a new 0.4 in your wallet to spend.  Bitcoin-Qt doesn't show you the address, but it's there.

This is how people can get into trouble with paper wallets - they think of it as an account with a balance.  You have to deal with the change or bad things happen.
Post
Topic
Board Bitcoin Technical Support
Re: Bitcoind crashed and no longer starts
by
evilpete
on 01/01/2014, 01:41:08 UTC
At exactly 8:30PM EST my bitcoind service crashed (out of nowhere) after running for several months:

Code:
Dec 24 20:30:39 bitcoin kernel: pid 3664 (bitcoind), uid 0: exited on signal 6 (core dumped)

Now it will no longer start, it dies with this message:

Code:
Assertion failed: (internal_key.size() >= 8), function ExtractUserKey, file ./db                                           /dbformat.h, line 96

The debug log only shows:

Code:
2013-12-25 01:49:00 Bitcoin version v0.8.5.0-gef14a26-beta ()
2013-12-25 01:49:00 Using OpenSSL version OpenSSL 0.9.8q 2 Dec 2010
2013-12-25 01:49:00 Default data directory /.bitcoin
2013-12-25 01:49:00 Using data directory /var/db/bitcoin/
2013-12-25 01:49:00 Using at most 125 connections (11095 file descriptors available)
2013-12-25 01:49:00 Using 2 threads for script verification
2013-12-25 01:49:00 init message: Verifying wallet...
2013-12-25 01:49:00 dbenv.open LogDir=/var/db/bitcoin/database ErrorFile=/var/db/bitcoin/db.log
2013-12-25 01:49:00 Bound to [::]:8333
2013-12-25 01:49:00 Bound to 0.0.0.0:8333
2013-12-25 01:49:00 init message: Loading block index...
2013-12-25 01:49:00 Opening LevelDB in /var/db/bitcoin/blocks/index
2013-12-25 01:49:00 Opened LevelDB successfully
2013-12-25 01:49:00 Opening LevelDB in /var/db/bitcoin/chainstate
2013-12-25 01:49:00 Opened LevelDB successfully

This is bitcoin 0.8.5 on FreeBSD 9.0 32-bit.  Disk space and RAM are okay.


Exactly the same here (except openssl 1.0.1e and 64 bit 11.0).  I tried a reindex but found I got the same errors during reindex that the Mac OSX folks typically had.  eg:  Invalid argument: not an sstable (bad magic number)

I looked at the 0.8.5 -> 0.8.6 patch to env_posix.cc that disabled mmap() for writing in LevelDB for OSX.  When I enabled that for FreeBSD as well, the reindex problem was solved.
Post
Topic
Board Bitcoin Technical Support
Re: transaction is over the size limit?
by
evilpete
on 31/10/2013, 07:39:42 UTC


I have no idea if the transaction is less than 10,000 bytes.. How am I to know this?

What does it mean when it says: "All outputs are 0.01 BTC or larger" (outputs? what is that?)


Besides the written explanation above, here is the rest of the info you need:

http://bitcoin.stackexchange.com/questions/7537/calculator-for-estimated-tx-fees
http://bitcoin.stackexchange.com/questions/1195/how-to-calculate-transaction-size-before-sending

In particular:  in*148 + out*34 + 10 plus or minus 'in'

Bitcoin addresses are not accounts.  The wallet metaphor is more appropriate.  You have a collection of individual payments, like a stash of banknotes of different sizes.  You can add them up, but they are still separate, just like putting two $20 bills in a wallet doesn't turn them into a $40 bill.

Inputs are these separate payments. Outputs are who you are paying.  Your change is an extra output coming back to you. Inputs are merged into outputs through this transaction.

If you have received 50 x 0.0001 payments, the total is 0.005. But to pay somebody 0.005, a transaction is created that sends all 50 inputs to one output.

In this case, we have:
148 bytes x 50 = 7400 bytes
34 bytes x 1, for a total of 7431.

However, the "output" is 0.005, which is less than 0.01 so a fee must be included.

The absolute minimum fee is 0.0001 per kb, so the absolute lowest fee you could pay is 0.0008 (~7.5k rounded up).

Change adds an interesting complication.  Suppose you wanted to pay 0.100 to somebody, but the best match of input amounts added up to 0.1003.  The transaction would be a collection of input amounts, to two outputs - 0.1 to the person you were paying, and 0.0003 back to you for change.  This also triggers the "output < 0.01" rule.

For what its worth, yes, most people agree this fee structure is far less than optimal, but its what we're stuck with for now.  Fixing it effectively requires everyone to upgrade.  If you look at http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html we've still got people running 0.3.x through 0.7.x from years ago.  This is going to take a while.

You can see the work being done in 0.9 to make the 0.9 code self adjust to network health when deciding what the fee limits will be.

Make no mistake, this is about the bitcoin network and blockchain health.  It is denominated in bitcoin and was set up when spam was a bigger problem and bitcoin trading value was nothing like it is today.

BTW; you can coalesce small "dust" (what these tiny amounts are called) into larger ones.  It takes a bit of effort, and you already have to have a bunch of bitcoin to do it.  eg: if you have 0.01 btc and a collection of 0.00001's you can pay yourself 0.01 btc + a bunch of the 0.0000xx's.  So long as you don't hit 10kb, and the inputs have aged enough to not hit the priority trigger, then you can merge these into larger coins.  But, it is slow and you already have to have some btc to piggyback the dust onto.

TL;DR: don't generate dust like this.  It's nothing but a headache - even more so for the recipient than the sender.
Post
Topic
Board Development & Technical Discussion
Re: large portion of network rejecting transactions?
by
evilpete
on 20/08/2013, 16:27:56 UTC
It would always be helpful to include a problematic transaction id or two so that folks can see what the actual problem is and not have to guess.

The network generally rejects non-economical dust outputs now.  This affects things like faucets etc where the faucet amounts often cost more in fees for the recipient to spend than they actually received.

https://en.bitcoin.it/wiki/Transaction_fees
Post
Topic
Board Off-topic
Re: Lavabit.com and Tormail Email Alternatives...
by
evilpete
on 09/08/2013, 05:38:11 UTC
He could move to Russia and continue operation Lavabit from there IMHO! It would be nice slap in the NSA face Grin
And Russia's any better?

Snowden's in Russia because it was a way to annoy the US.  They're not a country that usually springs to mind when one is asked for examples of a country that respects civil liberties or human rights.

Hint: they just got their version of SOPA.
Post
Topic
Board Pools
Re: [1400GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
by
evilpete
on 29/07/2013, 21:15:13 UTC
TRC was flooded with hashpower, I think they 51%'ed it as well to orphan other miners blocks.  The difficulty was jacked up through through the roof, then then left.

https://bitcointalk.org/index.php?topic=261986.0

This is the downside of short interval difficulty adjustment.  The two week one on bitcoin may be annoying but the short ones are open to far more abuse.
Post
Topic
Board Pools
Re: [1100GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
by
evilpete
on 14/07/2013, 19:49:44 UTC
...but everybody keeps their ASICs in pocket :-/
yes, because the switch over is not done yet. I will point my ASICs to p2pool when switch over is done and it's working with the new 30sec interval.

If you had larger ASICs, you could probably make the difference.
Post
Topic
Board Pools
Re: [1100GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
by
evilpete
on 10/07/2013, 05:55:05 UTC
how many percent was updated?  where can we see? can wait for the switch.

I'd also like to know what percentage of the network has upgraded. Based on http://p2pool-nodes.info/, its 96 nodes are still at < v13.0 and 32 at > v13.0, so around 25%.

p2pool-nodes.info only shows a portion of the public nodes.  A bit over a week ago it was only showing 30-40 nodes but I was able to tweak my pool to attempt to explore and it found ~260 public nodes.  p2pool-nodes.info hadn't found my public node for about 5-6 weeks.  It finally updated last week sometime.

Treat p2pool-nodes.info as a sample, not an exhaustive list.
Post
Topic
Board Development & Technical Discussion
Re: What if the devs are ordered by a US judge to include a government backdoor?
by
evilpete
on 07/06/2013, 00:54:51 UTC
Folks are asking the wrong questions.  The more interesting questions are:

If it were so ordered, how might it be done?

If it were done, how could it be kept hidden to stop it being circumvented?  (given that the point of bitcoin is that people are supposed to be a validating node.. right?)

What would they really want, anyway?  A copy of transactions? (like the public block chain? oh wait..)  Map addresses to people?  (That's what the FinCEN MSB/etc stuff is for)


Backdoors like registering private keys or even public addresses would never work (too many alternative clients, a huge can of worms - people would remember Clipper quickly)

Backdooring miners is academic - all they're doing is gathering signature transactions into a blockchain.  You need to private keys (see above) to take somebody's BTC.  They can't tamper with the blockchain, it would be rejected by the rest of the network.  The block chain is to provide consensus of which version of transaction is the right one, it doesn't make actual transactions.


No, its far easier and more practical to raid your home at first light, seize everything you have, and present you with alternatives so horrible that you'll cave.  A bit of shock and awe goes a long way to keep people in line.

There's no gain for "the government" to backdoor the bitcoin code when there's far more effective tactics.  Be more worried about the highly effective, low tech attacks.  Its hard to spend your bitcoins if you're in prison.
Post
Topic
Board Development & Technical Discussion
Re: bitcoind "Insufficient funds", but funds are sufficient
by
evilpete
on 04/06/2013, 05:35:24 UTC
Once you add the 0.0005 (what you've set for paytxfee by default if you haven't changed it) you get:

.034700001+0.0005 = .035200001

That's more than your starting balance.  Or I need more coffee.
Post
Topic
Board Bitcoin Discussion
Re: Boycott 0.8.2
by
evilpete
on 06/05/2013, 20:34:31 UTC
If we refuse to upgrade will we be treated differently when it comes to making transactions with small amounts? Will we even be included in the blockchain?

If all your peers are running with the settings at 0.0001, then this happens as they drop it:
2013-05-06 20:29:16 ERROR: CTxMemPool::accept() : nonstandard transaction type
Your client will keep retrying and eventually it might find a peer that will relay it, and with luck it'll reach a miner that will mine it.

Of course, since 0.8.2 changes it from a hard coded, compiled in setting to a user-setting then who knows?  It can be lowered and 0.8.2 gives people the choice.  Heck, people can even increase the minimums on their p2p node if they wish.
Post
Topic
Board Bitcoin Discussion
Re: Boycott 0.8.2
by
evilpete
on 06/05/2013, 16:51:46 UTC
So... Let me get this straight... Everyone is all wound up because the fee's have changed...

If you actually read you understand but you are clueless, so I take pitty on you.
I did, I read the code the only real change in the behavior is it's checking a run time variable vs a constant.. and said run time variable is different then the constant, if one wants the old behavior pass old value to new run time variable. Or if really concerned write a patch that changes that magic number back to the old magic number and put in a pull request.

It also calculates the threshold where a transaction can't be spent without costing so much in fees that it's not worth spending. This is derived at runtime from the values you quoted.

And if such a "dust" transaction comes through the p2p network, it ignores it.  If a miner mines it, then so be it, but the node itself won't contribute to propagation of the dust spam.

Miners can set this threshold at runtime easily instead of having it compiled in.
Post
Topic
Board Development & Technical Discussion
Re: Is a compromised bitcoin wallet secured after changing the password?
by
evilpete
on 05/05/2013, 03:59:44 UTC
If the wallet has been stolen and not yet spent then they have your private keys and the next 100 pre-generated keys your client was planning to use.

You need to move everything to another entirely separate wallet, ASAP.  Then back up the compromised wallet and make a new one from scratch..

You should keep the old wallet in case somebody ever sends something to an old address and you want to retrieve it - before somebody else does.  Just make Damn Sure(TM) you don't reuse any of its addresses.