Bitcoin Forum
May 12, 2024, 07:39:07 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 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 ... 288 »
1221  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core 0.14.0 release candidate 1 available on: February 19, 2017, 01:44:04 PM
The release notes are still a bit in flux.

There are some really nice performance improvements in 0.14 which aren't mentioned in the release notes yet.

Another major feature in 0.14 is support for after the fact fee bumping-- if a transaction is taking longer to confirm than you want, you can increase the fee.

The release notes make it sound like getinfo is gone completely. This isn't the case, it has been marked deprecated and will be phased out in the future. But for now the only change is that the help for it tells you not to use it anymore.
1222  Bitcoin / Development & Technical Discussion / Bitcoin Core 0.14.0 release candidate 1 available on: February 19, 2017, 01:42:38 PM

https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2017-February/000032.html

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Release candidate 1 of a new major bitcoin Core release, version 0.14.0, has
been made available.

This is a release candidate for a new major version release, including new
features, various bugfixes and performance improvements.

Preliminary release notes for the release can be found here:

    https://github.com/bitcoin/bitcoin/blob/0.14/doc/release-notes.md

Binaries can be downloaded from:

    https://bitcoin.org/bin/bitcoin-core-0.14.0/test.rc1/

Source code can be found on github under the signed tag

    https://github.com/bitcoin/bitcoin/tree/v0.14.0rc1

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.14.0 final, otherwise
a new rc will be made available after these are solved.

Please report bugs using the issue tracker at github:

    https://github.com/bitcoin/bitcoin/issues

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJYqYjyAAoJEHSBCwEjRsmmyjwH/3J4ML+yUgj7j6hGr9/cQm4T
5I1lcGNIeh12qlJV/0ZlOI4U1gi+PgDUlGVflKWNN87h/S6XebGE5ovjF1bNZEed
KRB/gQTXQIg4v/rObslibs8W1LESGB6Ttif7icvUZ7uMFqP7N76tMOEQM8WGK6NZ
6v0fqTC15RoEkv+/y5ZwSYPm5F+ZT0JEBXMIIQ873nQ45JckJ3+aU4i321gn0KDk
kBm348wYqOqdEpQ7hpbMPStoXMrfsijM00FK5/98F5LTLubbf0a0+cdZDVak1t44
roLA2dfh3cYHFncEBFO4nJ71iSnbaqgfx9HRilfCF5O4zfDcZgWRKkUTHft1Z9o=
=2z+P
-----END PGP SIGNATURE-----
1223  Bitcoin / Development & Technical Discussion / Re: FeeFilter message (minmempoolfee) and privacy on: February 18, 2017, 12:27:45 AM
It's not clear to me if you understand the purpose of fee filter.

The purpose of feefilter is not to "find out the fee", the purpose is so that peers will not waste bandwidth INVing you transactions that you will not bother accepting.

The mempool message is not supported by all nodes, and is delayed and restricted for privacy reasons.

Similarly, reject messages are not universally used, and are not mandatory. There has been some recent discussion about eliminating most of them from the protocol since most are never used by any application and serve no purpose but wasting bandwidth and harming privacy.  (They were not originally in the protocol, their addition was somewhat controversial, and they have not turned out to be useful for the things they were claimed to be useful for).

The settings are also just one privacy vector. The minfee your node has depends on the settings as well as the history of limit reaching events that it has seen.  As a result, there is some information leakage as a node moves connections around the network. It isn't a significant leakage, but it costs basically nothing to decrease it a little.
1224  Bitcoin / Development & Technical Discussion / Re: Post your SegWit questions here - open discussion - big week for Bitcoin! on: February 15, 2017, 06:18:21 PM
The network must consent, but it has been done successfully in the past, in one day. No politics in that statement.
No politics, only dishonesty, enh?
1225  Bitcoin / Development & Technical Discussion / Re: Is my method a secure way to gather entropy? on: February 15, 2017, 09:51:19 AM
-snip-
That is my thought process.

You somehow assume asking a search engine will improve things, but it wont. You would just encode the information in a different way. Anyone that knows your keywords will find the same results[1]. If your initial keywords are not randomly generated, neither are your results. You also open yourself to several new attack vectors (e.g. MITM and Sybil) because you rely on information provided by others. Its significantly more difficult to manipulate a building you are about to take a picture off[2] than intercept your internet traffic and feed you predetermined data based on knowledge of your algorithm. If you really want to bake your own PRNG I suggest you follow piotr_n's advice. What you came up with might work for some time, until someone has a (strong) interest to make it work in their favor.

[1] within reason. There is a chance that different results will show up based on googles profiling or other factors.
[2] or the sound a busy intersection makes, etc.


This can't be emphasized enough. The OP's fancy scheme is just a few more bits of key material (which they've now made public). Real attackers search not just over the words but over the methods, and this scheme has added little to no actual entropy-- it has just added complexity and serious additional leak risks.  It is the worst kind of security theater.

Unfortunately, I've found that when someone has gone down this rabbit hole they often become addicted to the complexity of their ritual-- like move "conspiracy wall"-- they weave together steps which don't help and sometimes hurt their security, but are unshakably convinced that it is the most secure method ever.  ... I've given up trying to convince them otherwise... but I comment so that someone who comes across this stuff with a spotless mind will not gain the impression that people think it is good it isn't.

1226  Bitcoin / Development & Technical Discussion / Re: Block-size debate solution on: February 13, 2017, 03:06:39 AM
I wouldn't believe Mike Hearn if he told me the sky was blue-- but regardless-- we all learn, and what I quoted was written by Satoshi years later. (I also wonder if that was the email that Hearn posted while editing out mention of payment channels, -- I know he did that in one instance)
1227  Bitcoin / Development & Technical Discussion / Re: Block-size debate solution on: February 12, 2017, 11:12:09 PM
Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.
1228  Bitcoin / Bitcoin Discussion / Re: So who the hell is still supporting BU? on: February 11, 2017, 07:41:58 PM
wake up. read something.
"Jet fuel can't melt steel beams!"

Please.

Old nodes do not relay, display as unconfirmed, or mine segwit transactions. At no point are they cut off from the network in any way.  By contrast, your desperately proposed hardforks would force all non-participating systems into a separate network.

But keep on, I enjoy watching you turn red faced as people simply laugh off your constant misinformation.

It's confidence inspiring to be so opposed by the dishonest and the deranged.
1229  Bitcoin / Development & Technical Discussion / Re: List of people who have had commit access to Bitcoin Core on: February 02, 2017, 06:21:08 AM
Quote
having been given the position

I think it would be more correct to say that it was recognized that he was already doing it.  Appointed positions often don't make sense in Open Source, because it matters a lot more what people do than some kind of title. 
1230  Bitcoin / Bitcoin Discussion / Re: As it turns out, Craig Wright actually is Satoshi! on: January 27, 2017, 04:38:06 AM
franky1 is now also an enemy of fungiblity and not just decentralization? color me surprised.

FWIW, rumor I'm hearing is that Wright is going to be the marketing face for some a new altcoin.   If anyone is selling futures on it, I'm interested in shorting it. Tongue
1231  Bitcoin / Bitcoin Discussion / Re: As it turns out, Craig Wright actually is Satoshi! on: January 27, 2017, 02:20:48 AM
In this thread, large block maniacs show that their judgement is equally poor in other domains.
1232  Bitcoin / Development & Technical Discussion / Re: can anyone trace any relation between two Adress . on: January 26, 2017, 05:52:39 PM
Lite wallets all transmit a list of their addresses (or some equivalent) to the servers they use to get data about the network. Doing so obviously links your addresses together.  If you're running a full node this isn't an issue.
1233  Bitcoin / Development & Technical Discussion / Re: Post your SegWit questions here - open discussion - big week for Bitcoin! on: January 26, 2017, 10:01:12 AM
Hmm well I've started reading the arguments of the Bitcoin Unlimited project, and they are simple and concise. As painful as it is, I may start running their software. I feel it's the only way I can send the message to the core devs to
That isn't the message you send me by running it.

Quote
Segwit, only 25% have adopted it!
62% of listening nodes are signaling segwit support right now.
1234  Bitcoin / Bitcoin Discussion / Re: SegWit yay or nay? come vote here. on: January 25, 2017, 11:15:19 AM
I think that is overly exaggerated. If my node is currently connected to several old nodes, I don't expect that to change post-Segwit activation. However, I know that I may be wrong. I have not looked into it.
Connection behavior is the same pre and post segwit activation.  Having the network topology change all at once would be an unnecessary risk.
1235  Bitcoin / Development & Technical Discussion / Re: Configure Core not to download blocks or relay tx automatically on: January 25, 2017, 06:33:41 AM
https://github.com/laanwj/bitcoin-submittx
1236  Bitcoin / Development & Technical Discussion / Re: Idea: XPIR for more private lightweight nodes on: January 24, 2017, 09:56:33 AM
Percy++ can do single server... though it's much slower than the multi-server mode.  I think it may be using the same kind of crypto as xpir for the the single server... not sure which of the two is faster. (I wasn't aware of xpir before your message.)

All of this stuff is super slow, but fast enough to be usable. It just needs a lot of glue work.


With respect to the multiserver assumption-- well if due to performance reasons your options are multi-server OR no PIR-- the multiserver is still better than nothing. It also has the advantage that no crypto break could ever compromise your privacy, where the single server PIR has the unfortunate property that if the server logs your queries and then later it's discovered the crypto was weak, your privacy could be lost.

I also think Percy++ can combine the two. E.g. multiserver, but if they cooperate then you're still protected but I could be misremembering. The elaborations are kind of moot when AFAIK no one uses PIR for anything anywhere. Smiley
1237  Bitcoin / Development & Technical Discussion / Re: Idea: XPIR for more private lightweight nodes on: January 24, 2017, 12:50:01 AM
Search bitcoin-wizards logs for percy++  which is another PIR library; there have been some similar proposals to yours.

We added functionality in the Bitcoin Core RPC 'importprunedfunds' that could be used to import transaction data retrieved from this kind of PIR scanning service. I was thinking very much along the same lines as you with a free queue and then the ability to use blind tokens to add priority to entries in the queue.


It's possible to avoid downloading that initial index:

Create that index.

now build a binary tree over it e.g.   the rood node says [go left for <= 1WWWW..., right for the rest]
then the next layer down has [go left for <= 1FFFFF..., right for rest] [go left for <= 1kkkkkk... right for rest]
then the later below that would have four entries and so on..

each row of the tree in a separate database... then you just make multiple queries with the PIR hiding which of the nodes you are reading..
until you get to the bottom layer and know what index your spk is at.

In practice sending the whole index is probably fine.


I'm not sure if XPIR does something special here, but normally all the results have to be the same size.. so the fact that there are wildly different numbers of transactions connected to addresses has to have something done about it.

1238  Bitcoin / Bitcoin Discussion / Re: SegWit yay or nay? come vote here. on: January 23, 2017, 06:44:22 PM
OK, should I say then, they are "fuller"? According to this chart it was in November when the average block size passed the 900 kB size regularly. Since then the number of days/hours where we have more than 20.000 unconfirmed transactions in the waiting list is increasing.
Average blocksize is a pretty useless metric there, because it's highly distorted by miners that produce empty blocks  (or nearly empty blocks)-- which are still as full as they're going to get.  More useful is the n-th percentile size, which is ~1MB for most values of N... or the rolling maximum of the rolling minimum.
1239  Bitcoin / Bitcoin Discussion / Re: SegWit yay or nay? come vote here. on: January 23, 2017, 12:08:23 AM
Since November, we've had multiple days with full blocks.
Your comment seems strange to me, virtually every block is full, and has been for most of the last year, barring some low times on weekends. This isn't in and of itself a problem.

And sure more capacity might be needed, but the lack of urgency from the broader community around segwit is pretty good evidence that it isn't currently.  Talk is cheap. Smiley
1240  Bitcoin / Bitcoin Discussion / Re: SegWit yay or nay? come vote here. on: January 22, 2017, 07:07:34 AM
For those who don't know it, Franky1 appears to have a full time job lying about segwit on Bitcoin talk.  I see that he now has technobabble charts to match his technobable claims. The graphs look sciency but actually have nothing to do with Bitcoin at all-- no part of Bitcoin before of after segwit has any resemblance to either of those meshy graphs.  He's stuffing that stuff into his posts in order to make people who don't know much about the technology believe that he knows more than them.

I have him on ignore and I strongly recommend other people set him on ignore too.

I got asked to post some corrections here, so I am.

BUT before confirmation because it appears as signatureless tx (anyonecanspend) old nodes can cause issues.
Pre-segwit nodes know they don't understand segwit transactions so they simply do not relay or mine them. They don't cause any issues.  The reason they do not relay or mine them is because segwit uses some intentionally constructed forward compatibility in the protocol, which was put in by Satoshi specifically to enable new signature systems.  They'll tolerate things using this forward extensibility when they show up in blocks, but because they can't completely judge the validity on their own, they don't mine them (or relay them) themselves.

Quote
this is why 0.14(the implementation with p2wpkh and p2wsh key generation wallets) wont be released before activation.
0.14 will be released in Feburary/March and has nothing to do with segwit. Segwit support went into 0.13.1.

Quote
and then after activation, 0.14 wont connect with non-segwit nodes for relaying unconfirmed transactions to avoid the silly things that happen at unconfirmed relay level.
No, 0.14 is exactly the same as 0.13.1 with its connections and don't do anything special with relaying unconfirmed transactions.  Sounds like you are mixing up the behavior of 0.14 with the behavior of pre-segwit nodes.

Quote
they could connect to old nodes and just relay old transactions. but lets be honest segwit-node users wont bother doing all the setting changes to mix and match tx's. so will just whitelist segwit nodes to make things simple

The behavior of segwit enabled nodes is no mystery. The software has been complete for almost a year now, and has been running on the majority of the nodes on the network is months.  They don't "whitelist segwit nodes" to make things simple or otherwise.

Quote
segwit will divide the network at unconfirmed tx relay level
To avoid any instantaneous disruption of the network topology segwit nodes make no changes to their connection behavior when segwit activates. So if they would divide the network, it would already be divided.  ... though considering that over 61% of listening nodes are segwit, it would be impossible for them to 'divide' the network in two even if their behavior were like you inaccurately describe it.

Quote
technically its all the 'same network' (due to all nodes connecting to a pool), but the nodes become more biased to only communicate with their own kind. where it becomes more work for a pool to send out 2 different variants of a block. --witness
Nope. No more block versions are sent out, if someone wants a stripped block they get a stripped block. But every node creates stripped blocks for non-segwit peers that want them, and in no case does two versions need to be sent to any peer.

Quote
again core will try to advertise the need to get nodes to upgrade to gain more connections and be more part of their side of the network (although in their half truth twisting of words is one network)
And yet no such 'advertisement' has happened or is necessary.   That might have been the case if there was risk of segwit activating with only a couple percent of nodes being upgraded, but a couple percent was passed in the first few hours of 0.13.1's release.

Quote
this is why it should have been a proper network consensus rather than a emulated consensus of just the pools, so that by being a full network consensus before pools, allows the nodes to be ready and fully compatible rather than just SPV compatible to segwit
Again, 61% of reachable nodes. If a consensus of nodes were all that were required-- that would have long since been passed. But softforks do not require nodes beyond a bare minimum. They're safe with just mining.

Quote
as you can see by segwits own guide. if not upgrading they want you to set up another node to 'filter' your unupgraded node through a segwit node (facepalm) when sending old tx's but you wont receive new tx's. it also allows segwit nodes to be the controller of what becomes a 'valid block' or not. rather than the old node doing independent checks

The guide is also quite specific that you have the freedom to do nothing.  If you want segwit validation for the strongest security you can also get it without modifying your existing software and risking disruption of your operation.  This is pure flexibility that you have from a softfork, a free choice you can make or not make, which is ripped away from you by hardforks. In a hardfork you cannot retain your existing infrastructure at all, you must replace it with upgraded software which may be incompatible with the customizations and downstream modules you already have running.

There is no point in discussing SegWit in its current state as it lately became clear that miners won't support this update.

Segwit has more hashrate than BIP66 did this many days after start.  Your opinion is possibly being manipulated by malicious people who are exploiting the fact that it often takes miners a long time to upgrade to try to convince you that segwit will not activate.

It will activate if people want it and make their preferences known, no more, no less.  Contrary to franky1's claims I nor any of the other developers get paid based on segwit activating. We did our part.

Personally, I'm happy that it hasn't activated yet (though not so happy about the people lying about it).  The lack of urgency in getting it going coupled with the continued health and success of Bitcoin without any capacity increase just shows what a big stinking liar people like franky1 have been with their hyper-aggressive doom and gloom claims that Bitcoin was going to fail unless it had a capacity increase ASAP.
Pages: « 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 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 ... 288 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!