Bitcoin Forum
August 15, 2022, 01:01:18 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 [103] 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 ... 416 »
2041  Bitcoin / Development & Technical Discussion / Re: Bitcoin 0.12 release on: February 03, 2016, 05:22:15 PM
Uh, no -rescan? So, also no -wallet? I have a few different wallets. wallet1.dat, wallet2.dat, wallet3.dat

When I switch wallets, I usually have to shutdown Core, then start it with a -rescan while pointing to the other wallet.

What I could try to do, is make several separate folders or directories of core with each wallet, then prune each one. So for 3 different wallets, I'll be running 3 separate pruned nodes. Could also be separate machines (virtual or real.)

That'd work, though if I were you I'd just store the whole blockchain. At least on my machines, rescans tend to be a lot quicker than syncing.

In the future Core maybe needs something like:

- You keep the last n levels of ancestor transactions for each UTXO. Electrum servers do this. Then you can almost always rescan, but still save quite a bit of space (though the savings are unpredictable).
- Rescan using only the portion of the block chain that Core is keeping with the prune=<kept chain data in MB>. So if you do prune=20000 or something you'll probably always be able to usefully rescan.
- The ability to rescan by relying on an archival node (maybe one you trust) and bloom filters. Then you can run just one archival node and point your other nodes to it. Note that this is a massive privacy issue if you're relying on random public nodes.
2042  Other / Politics & Society / Rand Paul drops out of US presidential race on: February 03, 2016, 05:07:46 PM

Pretty sad. Very near the beginning of the presidential race he seemed to be doing quite well, but he ended up just not being good enough at politics.

I haven't been following the other candidates. Are any of them decent? IMO, the most important issue (especially for a president) is maintaining peace, and it seems like almost all of the candidates are way worse than Obama, ready to go recklessly into a deadly and expensive war.
2043  Bitcoin / Development & Technical Discussion / Re: Bitcoin 0.12 release on: February 03, 2016, 09:54:45 AM
the only thing you cant do with a purned node is help someone else to become a node, but thats not a requirement of a full node IMHO.

You also can't rescan, which I suspect is what people will end up missing the most with pruning.
2044  Bitcoin / Development & Technical Discussion / Re: Wondering out loud: Which should Chinese miners support - Core, Classic or another? on: January 31, 2016, 05:35:41 AM
What are your thoughts on OP's suggestion to sponsor a Core dev?

It's a good idea. Though perhaps it might be even better to hire someone whose job it would be just to effect communication between the Core devs and the Chinese miners. wangchun has been doing this to some extent, but I still feel like there is a severe lack of communication. I especially feel like the overall philosophy of Bitcoin which motivates everything Core does has not been adequately communicated to the Chinese Bitcoin community. In the Chinese->English translations I've read, I see a ton of misunderstandings.

Communication has become a problem in general, as well, though the language barrier makes it even worse. I really miss the days when all of the major miners, CEOs, etc. were quite often on IRC, directly talking with the Bitcoin experts and Core devs, and in the process becoming experts themselves.
2045  Bitcoin / Bitcoin Technical Support / Re: Possible to specify a different location for bootstrap.dat on: January 29, 2016, 12:45:39 AM
I think starting with Windows Vista, you can use MKLink to create junctions to different directories, while giving the appearance that the directory is in the same local directory. So you could use this to move your Bitcoin blockchain pretty much wherever you want.

mklink /j [Directory1] [Directory2]

Right. The location pointed-to by -datadir should always really contain your wallet-related files (wallet.dat, db.log, database directory, .lock) but in my experience it's totally fine to replace any of the other files/directories with symlinks.

I don't know whether mklink /j will create the right type of link, though. Isn't that for directories?
2046  Other / Meta / Re: Exact calculation of Trust Score on: January 27, 2016, 05:33:36 AM
The exact algorithm is here:
2047  Other / Meta / Re: Forum trust hack or bug. on: January 27, 2016, 05:30:14 AM
cryptodevil is trusted by dooglus, who is trusted by DefaultTrust, who is trusted by you. You can see this here:;full

You can remove him by adding ~cryptodevil or ~dooglus to your trust list (excluding them) or by removing DefaultTrust and replacing it with your own list. If you think that cryptodevil should not be on the default trust network, you should contact dooglus about it.
2048  Bitcoin / Bitcoin Discussion / Re: What would be Satoshi's opinion on blocksize debate ? on: January 26, 2016, 04:32:53 AM
See my comment here:

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

The point of that block number was to show how to make this change with reasonable advance notice, not to suggest a particular block number for doing the change. That post was made on Oct 4, 2010 when the block height was about 83530. Probably how he got block #115000 was that he rounded this to 80000 and added the expected number of blocks in 9 months (~35000). If he was actually suggesting that the change be made at that block number, then he would've had to have actually put this code into Bitcoin very quickly after his post there for his statement "it can start being in versions way ahead" to make any sense at all. (And clearly he didn't do this.)

This "flag day" approach is in fact the preferred way of doing hard forks among the Bitcoin Core devs.
2049  Economy / Auctions / Advertise on this forum - Round 164 on: January 26, 2016, 04:28:27 AM
The forum sells ad space in the area beneath the first post of every topic page. About 25% of ad income goes to the forum moderators as thanks for all of their work. (There are many moderators, so each moderator gets only a small amount -- moderators should be seen as volunteers, not employees.) The rest is stored in the forum's treasury (verifiably), where it sits until the forum needs it.

Ads are allowed to contain any non-annoying HTML/CSS style. No images, JavaScript, or animation. Ads must appear 3 or fewer lines tall in my browser (Firefox, 900px wide). Ad text may not contain lies, misrepresentation, or inappropriate language. Ads may not link directly to any NSFW page. Ads may be rejected for other reasons, and I may remove ads even after they are accepted.

There are 10 total ad slots which are randomly rotated. So one ad slot has a one in ten chance of appearing. Nine of the slots are for sale here. Ads appear only on topic pages with more than one post, and only for people using the default theme.

The ad lasts at least 7 days starting from when I put it up. (However, if you look at the ad history you'll see that ads usually get at least 8 days, and sometimes as many as 12, but this is random and definitely not guaranteed.)


Exact historical impression counts per slot:

Info about the current ad slots:

Ad blocking

Hero/Legendary members, Donators, VIPs, and moderators have the ability to disable ads. I don't expect many people to use this option. These people don't increase the impression stats for your ads.

I try to bypass Adblock Plus filters as much as possible, though this is not guaranteed. It is difficult or impossible for ABP filters to block the ad space itself without blocking posts. However, filters can match against the URLs in your links, your CSS classes and style attributes, and the HTML structure of your ads.

To prevent matches against URLs: I have some JavaScript which fixes links blocked by ABP. You must tell me if you want this for your ads. When someone with ABP and JavaScript enabled views your ads, your links are changed to a special randomized URL which redirects to your site when visited. People without ABP are unaffected, even if they don't have JavaScript enabled. The downsides are:
- ABP users will see the redirection link when they hover over the link, even if they disable ABP for the forum.
- Getting referral stats might become even more difficult.
- Some users might get a warning when redirecting from https to http.

To prevent matching on CSS classes/styles: Don't use inline CSS. I can give your ad a CSS class that is randomized on each pageload, but you must request this.

To prevent matching against your HTML structure: Use only one <a> and no other tags if possible. If your ads get blocked because of matching done on something inside of your ad, you are responsible for noticing this and giving me new ad HTML.

Designing ads

Make sure that your ads look good when you download and edit this test page:
Also read the comments in that file.

Images are not allowed no matter how they are created (CSS, SVG, or data URI). Occasionally I will make an exception for small logos and such, but you must get pre-approval from me first.

The maximum size of any one ad is 51200 bytes.

I will send you more detailed styling rules if you win slots in this auction (or upon request).

Auction rules

You must be at least a Jr Member to bid. If you are not a Jr Member and you really want to bid, you should PM me first. Tell me in the PM what you're going to advertise. You might be required to pay some amount in advance. Everyone else: Please quickly PM newbies who try to bid here to warn them against impersonation scammers.

Post your bids in this thread. Prices must be stated in BTC per slot. You must state the maximum number of slots you want. When the auction ends, the highest bidders will have their slots filled until all nine slots are filled.

So if someone bids for 9 slots @ 5 BTC and this is the highest bid, then he'll get all 9 slots. If the two highest bids are 9 slots @ 4 BTC and 1 slot @ 5 BTC, then the first person will get 8 slots and the second person will get 1 slot.

The notation "2 @ 5" means 2 slots for 5 BTC each. Not 2 slots for 5 BTC total.

- When you post a bid, the bids in your previous posts are considered to be automatically canceled. You can put multiple bids in one post, however.
- All bid prices must be evenly divisible by 0.05.
- The bidding starts at 0.50.
- I will end the auction at an arbitrary time. Probably the end time will be 7-12 days from the time of this post, though it could be anywhere between 4 and 22 days from now. (I will probably end the auction 1-3 days before the ads are scheduled to go up.)
- If two people bid at the same price, the person who bid first will have his slots filled first.
- Bids are considered invalid and will be ignored if they do not specify both a price and a max quantity, or if they could not possibly win any slots

If these rules are confusing, look at some of the past forum ad auctions to see how it's done.

I reserve the right to reject bids, even days after the bid is made.

You must pay for your slots within 24 hours of receiving the payment address. Otherwise your slots may be sold to someone else, and I might even give you a negative trust rating. I will send you the payment information via forum PM from this account ("theymos", user ID 35) after announcing the auction results in this thread. You might receive false payment information from scammers pretending to be me. They might even have somewhat similar usernames. Be careful.
2050  Other / New forum software / Re: "ignored by x members"? Potential quality improvement on: January 26, 2016, 04:22:30 AM
What used to happen was that users with many ignores would have their ignore button highlighted orange. But I removed it because it was rather taxing on the database and I don't think very many people used it. Maybe I could try bringing it back sometime.
2051  Economy / Auctions / Re: Advertise on this forum - Round 163 on: January 26, 2016, 04:19:17 AM
Auction ended. Final result:
Slots BTC/Slot Person
1 2.25
3 2.20 victorhing
3 2.20 FortuneJack
2 2.20 idsb2b
2052  Other / Meta / Re: Is this a backup site? (Warning! if not) on: January 22, 2016, 02:44:14 PM
There are no official backup sites for

I think that most of these sites copy's content so that they can confuse Google into showing their results high-up sometimes, and then they either have ads to make money off of this, or they operate as phishing sites. I don't know. Don't enter your password into any other site.
2053  Bitcoin / Development & Technical Discussion / Re: Does replacement interact with quantum computers? on: January 21, 2016, 09:28:48 PM
If QC comes into existence, then that is a very major problem which should be fixed ASAP in any case.

From a game theory perspective it doesn't make much sense for us to wait for the day where it is public knowledge that a QC exists. Given QC attributes as crypto-breaking machines, there's a history of similar crypto-breakthroughs remaining hidden.

It seems very unlikely to me that a QC will be created, then the tech will advance to the point that real-world keys can be broken in less than years, and all of this will be kept secret until it becomes an emergency. These government agencies are full of many people, and people are bad at keeping secrets. If this does happen, it can be survived due to the QC-resistance of Bitcoin addresses, but hurrying to plan for this seems like premature optimization. Especially when the current state-of-the-art in QC-proof signatures have massively larger signatures than ECDSA, and bandwidth is currently a pretty big bottleneck.

There is a flag for disabling the RBF policy, -permitrbf=0.

IIRC the Core devs do have code prepared for adding QC-proof signatures to Bitcoin as a softfork (using a variant of Lamport signatures optimized for minimal size, especially in the scriptPubKey), though AFAIK this code isn't public.
2054  Bitcoin / Development & Technical Discussion / Re: RBF transactions to be enabled at the next core update on: January 19, 2016, 10:53:39 PM
In order for a 0-confirmation transaction to get double spent (assuming you have zero influence on any amount of mining hardware/pool) without RBF, as a general rule most of the network needs to have not seen the transaction, AND the transaction needs to either not have been seen by the miners' nodes or not be a transaction that the miners will generally confirm.

Exploiting policy differences is the easiest way, and I'm not sure that you can ever really eliminate it because people will always have different policies. But there are other ways:

I think that you'll have a pretty good success ratio if you send the transaction directly to the merchant and simultaneously send the double-spend directly to some miners. The merchant and the peers around him will have one version, but miners will have the other. If the merchant is not running several nodes, then he probably won't even see the the double-spend until it gets into a block, since his surrounding peers won't relay a transaction that they view as a double-spend.

And there's always the Finney attack. If you're a miner, you can (for no additional cost) continuously try to double-spend your 0-conf transactions. If you happen to mine a block while the transaction still has 0 confirmations, then you double-spend it, and nothing can stop this.

Wouldn't it be possible for someone to sign a transaction that relies on input x, and has a "high" fee, save this transaction to a text file (or wherever), then sign a separate transaction that also relies on input x and has a "low" fee, and has the appropriate flags that "enable" RBF, and broadcast this transaction. Then they could simply use "sendrawtransaction' (which is significantly easier to use then "createrawtransaction" imo) to broadcast the conflicting transaction.

The Core GUI won't let you create conflicting transactions like that. You could do it by messing around with wallet backups or something, but again, it takes a fair bit of extra effort.

With Core's implementation of opt-in RBF, you can't (from the perspective of any given network node) replace an RBF-disabled transaction with an RBF-enabled transaction, and you can't replace a transaction with one having a lower fee. You can replace an RBF-enabled transaction with an RBF-disabled transaction.

This doesn't mean that others will not write guides on how to fraudulently double spend transactions, and that people will not design wallets/programs to help people fraudulently double spend transactions.

Probably, but that can happen with non-RBF transactions as well.

I am having difficulty finding reasons why RBF is better then CPFP and/or RBF is being implemented in core while CPFP is not supported (for the most part).

AFAIK CPFP isn't ruled out for Core. It's in Luke's fork. I'm not sure why it's not in Core. Maybe there are some performance problems with the existing code or something.

I see them as being complementary. If the sender is taking responsibility for confirmation, then he should use RBF; otherwise, if the recipient is taking responsibility then the recipient can use CPFP and the sender can opt out of RBF.
2055  Other / Meta / Re: Administration ignoring and erasing request to recover hacked account on: January 19, 2016, 06:37:58 AM
According to the seclog there was no password change or reset.

Changes by admins aren't logged there.
2056  Bitcoin / Development & Technical Discussion / Re: RBF transactions to be enabled at the next core update on: January 19, 2016, 12:17:43 AM
Who would use it and why?

The idea is that eventually most people will use it most of the time.

I don't know if this is actually exactly how it's planned, but how I imagine it working in the future is:
- By default, you'll send transactions with RBF. Then if the transaction doesn't confirm after a long time, RBF will allow you to easily increase the fee. You'll be taking responsibility for the transaction
- If a merchant requests that you not use RBF, you won't. Likely this request will be done via the Bitcoin Payment protocol (ie. bitcoin: URIs). So when you click "pay this" (or whatever it says) on a BitPay page, your wallet will automatically send the transaction without RBF. Then the merchant is taking responsibility for the payment, and they can adjust the fee later if necessary using the child-pays-for-parent (CPFP) mechanism. I'd expect most payment processors like BitPay to do this so that customers don't have to worry about fees and they can try to do fraud detection on 0-conf transactions.
2057  Bitcoin / Development & Technical Discussion / Re: RBF transactions to be enabled at the next core update on: January 18, 2016, 11:47:03 PM
Ok I know this isn't a technical question, but: What do businesses that regularly deal with Bitcoin have to say about this? And wallet developers? It still seems like a strange new feature.

As Peter Todd demonstrated with his Coinbase double-spend, it is (and always has been) very easy to double-spend 0-conf transactions even without RBF. In most cases, it is only slightly less difficult to double-spend with RBF compared to non-RBF.

I think that it's always been a hopeless effort, but some services try to predict when 0-conf transactions are high-risk using a number of network nodes listening for double-spends and other such things. For these, it's a simple matter to check for the RBF opt-in and treat these transactions as automatically high-risk.

I feel like most people are imagining that with RBF there's going to be a button in wallets that says "take back this money", but that's very unlikely. Right now you have to use createrawtransaction to send a RBF-enabled transaction, and in the future there will be a button to increase fees (or something), but I really doubt Core is ever going to provide an easy UI for fraudulently double-spending. As is the case today, 0-conf transactions will often work despite being totally insecure because a large percentage of people are honest, and of those who are dishonest, a large percentage of them haven't bothered to figure out how to double-spend.
2058  Bitcoin / Development & Technical Discussion / Re: RBF transactions to be enabled at the next core update on: January 18, 2016, 11:29:49 PM
So this means that when a transaction is broadcasted it has a flag saying that RBF can be enabled, or that it can't?

If all of the inputs of a transaction have nSequence = UINT_MAX or UINT_MAX-1, then they have RBF disabled. Sending transactions with nSequence = UINT_MAX is the default for ~all wallets.
2059  Bitcoin / Bitcoin Discussion / Re: Analysis and list of top big blocks shills (XT #REKT ignorers) on: January 18, 2016, 09:49:35 PM
Theymos wanted bigger blocks 2 years ago!
2060  Other / Meta / Re: Administration ignoring and erasing request to recover hacked account on: January 17, 2016, 08:31:33 PM
This doesn't verify for me:

Do you have any other proof that this PGP public key is correct?
Pages: « 1 ... 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 [103] 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 ... 416 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!