Bitcoin Forum
October 18, 2018, 03:13:17 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 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 ... 102 »
1  Bitcoin / Development & Technical Discussion / Re: Are blockchain tracking sites tracking Segwit adoption wrong? on: October 17, 2018, 10:02:57 AM
I think the best way to measure "Segwit adoption" is to look at how many segwit txs are inside the recently mined blocks.

Taking the last 1008 blocks (about one week of time) - up to block #546129:

There were 685908 segwit out of all 1727116 (non-coinbase) transactions - which means that about 39% of all mined transactions have been of segwit type.

If you look at the size (instead of tx count), you get 472263476 out of 984012845 bytes, coming down to about 47% of blocks' transactions space being used by segwit type.
2  Bitcoin / Development & Technical Discussion / Re: [Discussion] Dandelion - A protocol to hide transaction origin on: October 04, 2018, 10:09:18 AM
CoinJoins and Tor achieve two completely different kinds of anonymity. They are orthogonal to each other. You cannot compare them.
My point was that CoinJoin hasn't really been used in real life, while tor based centralized mixers have. And most likely will be in a future...
If you need to anonymize coins today, you'd rather choose a tor mixed over coin join.


The point of Dandelion is to have privacy by default. It is built into the P2P protocol. Users get privacy without having to think about privacy. OTOH, both Tor and CoinJoins require the user to actively think about and care about their own privacy. That means that most users aren't going to do those things because they don't think about or care about their privacy.

I'm just saying that the coin join idea, despite being very old (and having quite an advanced design by now) has not been delivered to a widely used bitcoin software.
And I'm just worried that Dandelion (or any other privacy enhancing feature) will end up the same way.

Both CoinJoin and Dandelion, in order to actually be practical, should be enabled in a widely used bitcoin software.
Exactly as you say: having it "built into the P2P protocol", so users can get "privacy without having to think about it".



I just use any of the send transaction web pages:
https://en.bitcoin.it/wiki/Transaction_broadcasting
Good for you. The vast majority of users aren't going to do that because they aren't aware of the privacy implications as you are. The whole reason something like Dandelion is being proposed is to get Privacy into the network protocol itself so that users who don't care about privacy still get privacy anyways.

Yes. However, before Dandelion gets delivers (if ever), it does not hurt to tell people that they already have options to hide transaction origin, had they cared to become aware of the privacy implications.
3  Bitcoin / Development & Technical Discussion / Re: [Discussion] Dandelion - A protocol to hide transaction origin on: October 03, 2018, 06:58:58 PM
but as the reality shows the devs are rather reluctant to introduce "privacy" features into bitcoin software.

I wouldn't say that's fair.  They're introducing this feature for starters, but then Schnorr will bring some more privacy benefits once that's good to go.  It sounds like testing is ongoing with Bulletproofs and Confidential transactions. 

OK then, bring it on.
I'll be happy to see it.
4  Bitcoin / Development & Technical Discussion / Re: [Discussion] Dandelion - A protocol to hide transaction origin on: October 03, 2018, 06:43:44 PM
I just use any of the send transaction web pages:
https://en.bitcoin.it/wiki/Transaction_broadcasting

some of them don't work through tor, but others do.

I can however understand that someone might have a need to anonymously broadcast new txs in a more systemic way, in which case my method will not be very good for him.
but then, as I say, there are safety concerns of people who'd have to participate in this kind of open source system.
5  Bitcoin / Development & Technical Discussion / Re: [Discussion] Dandelion - A protocol to hide transaction origin on: October 03, 2018, 05:53:32 PM
Tor masks your real IP. But if you send 2 or more transactions from a Tor node, your peers know that they received them first from you.
I am not an expert on tor network, but I don't think it is that easy.

if you're not careful the broadcasting server might know that both the transactions came from the same source.
But it won't know your IP.

Just restart your tor node/browser between sending different transactions and you should be fine.
Dark markets have been using Tor since the beginning of bitcoin and nobody ever find them by looking at the tx origin Smiley
6  Bitcoin / Development & Technical Discussion / Re: [Discussion] Dandelion - A protocol to hide transaction origin on: October 03, 2018, 05:48:46 PM
IMHO the technology to hide transaction origin was invented long time ago and by now it is quite advanced already.

Except that it isn't called Dandelion, but Tor.

Why to invent the wheel for the second time?
As mentioned earlier, Bitcoin shouldn't need to rely on an external service in order to have privacy. Privacy should be built into the protocol itself. Using Tor requires having Tor available on your machine and special configuring which most users won't do. However Dandelion is built into the Bitcoin P2P protocol itself so users don't need to do any special configuration to get it to work, the software just works out of the box.

It is a nobel approach, but as the reality shows the devs are rather reluctant to introduce "privacy" features into bitcoin software.
And I can't blame them - it's a savage world were living in.

For instance, look at the "coin join" idea - it is at least 6 years old.
But still today the best and only reliable way to anonymize your coins is to push them through a tor mixer service.
Because nobody wants to put his head on providing such services. Or even developing the technology.
7  Bitcoin / Development & Technical Discussion / Re: [Discussion] Dandelion - A protocol to hide transaction origin on: October 03, 2018, 05:31:39 PM
IMHO the technology to hide transaction origin was invented long time ago and by now it is quite advanced already.

Except that it isn't called Dandelion, but Tor.

Why to invent the wheel for the second time?
8  Bitcoin / Development & Technical Discussion / Re: NODE_NETWORK_LIMITED - what is it? on: September 28, 2018, 07:08:38 PM
Ok, thanks
9  Bitcoin / Development & Technical Discussion / NODE_NETWORK_LIMITED - what is it? on: September 28, 2018, 03:21:25 PM
I've noticed the recent core nodes (v0.16.0 or higher) by default introduce themselves with services bit 0x400

Then I read (in src/protocol.h) this means that the node only stores the last 288 blocks..

Code:
   // NODE_NETWORK_LIMITED means the same as NODE_NETWORK with the limitation of only
    // serving the last 288 (2 day) blocks
    // See BIP159 for details on how this is implemented.
    NODE_NETWORK_LIMITED = (1 << 10),

Is it true?

Also BIP159 says "Status: Draft" and defines NODE_NETWORK_LIMITED as:
Code:
If signaled, the peer MUST be capable of serving at least the last 288 blocks (~2 days).

So I'm a bit lost here..
10  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 24, 2018, 03:30:43 PM
You stop judging implementations that you haven't even made an effort to see.
I don't need to see it; you've already described it as a one-person (garbage) project.
Then you know very little about software development, my friend.
In my life I've made many one-person projects and those who paid me for them were never disappointed.
And unlike you, they weren't idiots.

Number of reviewers doesn't mean shit.
When it comes to 0 reviewers vs. decent number of reviewers, that's objectively false.
Obviously not always, as the event we're talking about clearly proves.

Code created entirely by one person has an advantage of that person understanding it better.
Which generally lowers a chance of that person making a mistake while changing it.
11  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 24, 2018, 02:49:18 PM
No; stop using this thread as a means to promote the implementation that has 0 active reviewers and probably 0 users.
You stop judging implementations that you haven't even made an effort to see.

Number of reviewers doesn't mean shit.
We've just seen that all it takes is one celebrity saying "it's safe" and none of the dozens of reviewers is even going to question that.
Behavior of the crowd is a bitch. That's why I prefer to work alone.
12  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 24, 2018, 02:38:21 PM
No, sir. Your jealous comments are amateurish at best.

My software might not have been tested as much as satoshi's code base, but its proven to be working very well, has an excellent performance and it's very easy to work with because of its brilliant architecture.
Plus, most of all, it would not have accepted a block with a transaction that spends the same input twice, nor crash upon it. Which is what all this thread is about.
Who exactly was talking about your software? Classic deflection.
You were:
Quote
any attempt at a secondary implementation so far has been amateurish at best.
13  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 24, 2018, 02:26:56 PM
It seems to me that what we're observing here is central planers trying to defend their monopoly.
If you believe that there are central planers and a monopoly, then you don't understand Bitcoin.

And the fact that central planners have been stating for quite long that they "don't care about miners" is most likely only going to accelerate the process.
Miners are often idiots and don't decide anything (they shouldn't anyways).

So if Bitcoin is here to stay, new implementations coming into existence are inevitable.
Many have tried.
this is given that you completely ignore that any attempt at a secondary implementation so far has been amateurish at best.

And no matter how much you'd want to, you can't stop anyone from running a compatible yet alternative implementation of a bitcoin node.
If you want to, then you're free to swim in second-grade garbage. Smiley

No, sir. Your jealous comments are amateurish at best.

My software might not have been tested as much as satoshi's code base, but its proven to be working very well, has an excellent performance and it's very easy to work with because of its brilliant architecture.
Plus, most of all, it would not have accepted a block with a transaction that spends the same input twice, nor crash upon it. Which is what all this thread is about.
14  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 24, 2018, 01:41:50 PM
It seems to me that what we're observing here is central planers trying to defend their monopoly.
And need I to remind you that the very reason for Bitcoin to exist, being such a phenomenal success, is breaking a monopoly of central planners? Smiley

I'm not even trying to convince anyone that this monopoly is a bad thing, simply because I think that it isn't going to matter. If Bitcoin is here to stay, it is just a matter of time before the market players build alternative implementations, customized for their own needs. And the fact that central planners have been stating for quite long that they "don't care about miners" is most likely only going to accelerate the process.

I know for a fact that making a new implementation is not as hard as the legends say. With a proper team it can be done for a reasonable amount of money and the money invested is meant to pay back later.

Let's be honest, the current bitcoin core software/implementation is a direct inheritance of the prototype made by Satoshi. Some components were upgraded or replaced, but the general architecture has not changed since its inception. It's hardly the best architecture for any possible application, maybe even not the best architecture for any specific app.

So if Bitcoin is here to stay, new implementations coming into existence are inevitable. Not only because there are better ways to do what bitcoin core does, but also because there is (will be) too much money at sake and the stakeholders will not be willing to risk their money by relying on only one software implementation and the responsiveness of one team of people who don't even work for them.

And no matter how much you'd want to, you can't stop anyone from running a compatible yet alternative implementation of a bitcoin node.
15  Bitcoin / Development & Technical Discussion / Re: Why explorers have problems with segwit address? on: September 23, 2018, 07:55:45 PM
blockchair.com also supports bech32

https://blockchair.com/bitcoin/transaction/7ace1f5fa549df23c09f791933d82f513d5afbce07d7caf2b69ec047d45f8ab6
16  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 22, 2018, 07:19:02 PM
My point is: whenever such a catastrophic event happens we want to know about it as soon as possible, to try preventing the damage.
That is why having only one software implementation is a very bad idea.
That's why I said in an earlier post that having the same person run multiple software is good. I don't think that if everyone was running different software that the problem would be noticed significantly faster than if everyone were using the same software.

It doesn't have to be the same person.
Like in this case, if such an event happened that there was a block that was trying to spend the same input twice, my node would just not let it through and got stuck on one block, which would make me to analyze why, which would maybe trigger an alarm.
It's obviously better if more people run the node like mine. Because sometimes I'm busy Smiley
17  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 22, 2018, 06:21:27 PM
Fork would be much less of a problem than building block chain with blocks that inflate the coin supply without anyone realizing.

Existence of an unexpected fork is a serious alarm signal that the entire system can act upon, e.g by stopping any economic activity until the situation clears up.

But what are you going to do upon realizing that e.g. for the past week someone has been mining blocks that increased the amount of coins in his wallet by 10% of the extra BTC supply?

Obviously, as soon as you realize the screw up you make sure everyone upgrades the software.
But how are you going to handle the existing damage?
Well, I think in such case you basically end up with only two choices:

1) You let the guy keep the money he created out of a thin air, most of which he probably already spent anyway - all the expense of all the other bitcoin holders.

2) You invalidate all the blocks (transactions) from the past week - pushing the damage on the ones that accepted any payments during that time.

You can also think of invalidating the coins that were "added illegally", kind of like ethereum did with DAO hack (although they invalidated a reallocation of coins, not creation of new ones).
But assuming that the guy who came out with the exploit wasn't an idiot, they are long spent already and mixed with a "legal" coins, so that's not really an option.

My point is: whenever such a catastrophic event happens we want to know about it as soon as possible, to try preventing the damage.
That is why having only one software implementation is a very bad idea.
18  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 22, 2018, 08:50:24 AM
Since I might be the only person running an actual alternative, bitcoind independent implementation of a node, I promise to let you know when someone mines a broken block and all your software won't realize it.

Just try to not ban me from all your forums by that time Smiley
19  Bitcoin / Development & Technical Discussion / Re: bitcoin core client blocked on my network on: September 21, 2018, 01:28:25 PM
Hi, on my residence network, I cannot run Bitcoin Core, until I fire up VPN. Then the blocks are syncing and the transactions are showing up. Is there a way to configure the client to somehow connect, or once it is blocked in firewall, there is no way around it? Litecoin client works without a problem.
Thanks for helping!
Unfortunately it is very easy to block bitcoin core as it practically refuses to connect to any other TCP port than 8333.

There are some servers using a different port number, but you'd have to patch your own node to connect to them.
20  Bitcoin / Development & Technical Discussion / Re: How can I verify ECDsa signature that I made? on: September 21, 2018, 01:10:52 PM
(there is an extra 01 in yours)

That is not "extra", that is sigHashType (01 for signall).

then your length fields are screwed up.

Code:
0100000001eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2010000006b483045022100c3835cd9615ad7bf13ce68498ca4262794f8e1b481020107234e99a675710b40022070cd0c818f53b937e308ce4a824e75657875b3dabeea2eb9e377f18efdeb86e901210250863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b2352ffffffff01605af405000000001976a914097072524438d003d23a2f23edb65aae1bb3e46988ac00000000
Pages: [1] 2 3 4 5 6 7 8 9 10 11 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 ... 102 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!