Gold collapsing. Bitcoin UP.

[freetrader]

some kind of minor change in signature scheme would be necessary

The gnarly thing about this is that it touches a central cryptographic primitive in Bitcoin.
Ideally one would move to using another established signature scheme.
If anyone has thoughts on this, feel free to expand on them here or by PM to me, I am most interested...

 

[johnyj]

i think this is wrong.

classic nodes cannot simply change the TX it sees on the core chain.
all it can do is rebroadcast that exact same TX on its own chain.
which is interesting
if i get a payment on the core chain, i could just take that TX and broadcast it on the classic chain and get the paid both classic and core coins!

It is easy for classic software to have some built in mechanism to prevent a spent UTXO on core chain to be spent again on classic network, it just need to check the core chain and mempool to make sure an UTXO has not been spent. But classic can not prevent a coin first spend on classic chain and then spend on core chain, that is out of control of classic
[doublepost=1461064317][/doublepost]

@johnyj

There is no problem with doubling the supply of coins to 42M from 21M due to Core and Classic ledgers both existing. Everyone still owns the same percentage of the total ledger by default (and you can check the math to see that this remains true automatically even if Corecoins and Classiccoins have totally different prices), which is all that matters in terms of sound money.

If that isn't clear, note that 1BTC is just a shorthand for some small percentage of the total Bitcoin ledger, and that percentage is unaffected by making more copies of the ledger. You could have 7 forks and 147M BTC but everyone's stake and purchasing power remains the same by default in every ledger and every combination of ledgers, regardless of price changes or the failure of any fork-prong.

I think @freetrader is correct that some kind of minor change in signature scheme would be necessary along with the fork so that transactions intended for one side of the fork wouldn't automatically happen on both sides of the fork.

Meni used to have this view, but for anyone who don't have bitcoin, it is inflation like QE. Notice that bitcoin's value is supported mostly by purchasing from those who don't have bitcoin, not who have

 

[satoshis_sockpuppet]

@SysMan
The market is already reacting very positive to this
https://www.reddit.com/r/Bitcoin/comments/4fgpqi/bitfury_and_bitclub_network_are_the_first_miners/
Seems like SW will be a huge success if you take a look here:
http://coinmarketcap.com/currencies/ethereum/

 

[freetrader]

@johnyj

Meni used to have this view, but for anyone who don't have bitcoin, it is inflation like QE. Notice that bitcoin's value is supported by purchasing from those who don't have bitcoin, not who have

Only if one believes that several Bitcoin forks would co-exist for a lengthy amount of time with anything resembling equal valuations.

This is already highly unlikely, since forks sort of force the market to make up its mind regarding which one it considers valuable. The essential process is by giving that fork currency increased utility, and decreasing utility of the lesser favored.

While I would generally agree with the argument "bitcoin's value is supported by purchasing from those who don't have bitcoin", it's not quite that simple, or else a rising Bitcoin price would likewise disenfranchise an increasing number of people. One would then have to argue that price inflation is detrimental as well.

It's well illustrated by the frequent questions on Reddit such as "where can I buy $15 worth of Bitcoins?"

 

[sickpig]

n fact something like this is being done in BU (xtreme thin blocks etc), but the relay network has a more advanced tech that I hope it will be implemented in BU in the future: the client remembers the txs sent to every peer so to send personalized xtreme blocks for each one of them instead of the same one for every peer.
This comes with a cost in memory and cpu, of course, but it's a really nice improvement.

Do you care to expand a little on relay algorithm user by RN ?

Because I've read here https://bitcoinfoundation.org/a-bitcoin-backbone/ that:

"[Matt] has also implemented a highly optimized block relaying tool, which avoids re-transmitting more than 95% of the transaction data in “new block” messages."

95% is the same kind of bandwidth reduction we get in block propagation using Xthin. So I wonder if I'm missing something obvious...

 

[Zarathustra]

poor brg444 lamenting me not getting permanently banned from reddit.how many dozens of times has brg444 doxxed me? and laughed about it gleefully with a clear intent to hurt? he acts so righteous.

when this Hashfast case is over, these clowns are going to be so embarrassed when i am able to talk about the details of what actually happened.

I'm permanently banned there now for 'personal information' about that doxxing idiot, who already everybody knows via Twitter and Facebook.

 

[Dusty]

I think @freetrader is correct that some kind of minor change in signature scheme would be necessary along with the fork so that transactions intended for one side of the fork wouldn't automatically happen on both sides of the fork.

Ideally one would move to using another established signature scheme.

No change of signature scheme will save you: the fact is that if you have some bitcoins on the blockchain before the fork, you have the private keys to control them.
And if you have the private keys you can sign in whatever new scheme you come up in every chain. If you can't sign them then you do can't control your coins, and hence you was not owning them before the fork.

95% is the same kind of bandwidth reduction we get in block propagation using Xthin. So I wonder if I'm missing something obvious...

Yes, the technique is quite similar with the difference (for what I understand, but I never bothered to check the sources) that the relay network keeps track of which transactions he transmitted and received for every peer it is connected to. So, when it assembles a thin block, he knows in advance which transaction of the block each peer is missing and can create a special thin block (potentially) different for each one where there is a short hash for every tx the peer should already know and the full tx that he should not.

For what I know (please someone correct me if I'm wrong), BU this a thing very similar to this, but the thin block it prepares is the same relayed to all his peers, so someone may receive a tx he already knows, or on the contrary he may have to ask the tx data for some tx hash he received but he does not know about.
[doublepost=1461069195][/doublepost]

I'm permanently banned there now for 'personal information' about that doxxing idiot, who already everybody knows via Twitter and Facebook.

Who is this brg444? I remember it from trolltalk where he was very vocal about sidechain benefits...

 

[johnyj]

@johnyj

Only if one believes that several Bitcoin forks would co-exist for a lengthy amount of time with anything resembling equal valuations.

This is already highly unlikely, since forks sort of force the market to make up its mind regarding which one it considers valuable. The essential process is by giving that fork currency increased utility, and decreasing utility of the lesser favored.

While I would generally agree with the argument "bitcoin's value is supported by purchasing from those who don't have bitcoin", it's not quite that simple, or else a rising Bitcoin price would likewise disenfranchise an increasing number of people. One would then have to argue that price inflation is detrimental as well.

It's well illustrated by the frequent questions on Reddit such as "where can I buy $15 worth of Bitcoins?"

When you blend the value discussion in technical solutions, it becomes complicated, since all the value forecasting have short term and long term scope. Short term wise, not doing a hard fork might even generate some market stability and even make the price rise for a while, but long term wise it can be a way to sure death if the decentralization property is destroyed

Because no one can forecast the distant future, they might prefer a short term gain over a long term gain, I don't think the collective wisdom of the community can see through the uncertain future, every move is a speculation, not making any move is also a speculation by betting on the status quo

 

[freetrader]

No change of signature scheme will save you: the fact is that if you have some bitcoins on the blockchain before the fork, you have the private keys to control them.
And if you have the private keys you can sign in whatever new scheme you come up in every chain. If you can't sign them then you do can't control your coins, and hence you was not owning them before the fork.

Yes, if you control the private key you can do whatever you want with your coins.
What we were talking about is involuntary reproductions of transactions across forks by means of bridge nodes doing more or less advanced translation (none if the transactions remained identical).

 

[sickpig]

For what I know (please someone correct me if I'm wrong), BU this a thing very similar to this, but the thin block it prepares is the same relayed to all his peers, so someone may receive a tx he already knows, or on the contrary he may have to ask the tx data for some tx hash he received but he does not know about.

Quoting relevant part of BUIP010:

Node A is behind by one block and makes a thinblock request to Node B in the following way:

1. Node A creates a bloom filter seeded with the contents of its memory pool.
2. Node A sends the bloom filter along with a getdata request to Node B.
3. Node B sends back a "thinblock" transaction which contains the block header information, all the transaction hashes that were contained in the block, and any transactions that do not match the bloom filter which Node A had sent.
4. Node A receives the "thinblock" and reconstructs the block using transactions that exist from its own memory pool as well as the transactions that were supplied in the thinblock.

so it seems to me that Xthin is almost equivalent to RN because txs already present in node A mempool are not retransmitted again (*).

lastly, a nice picture (courtesy of @Peter R):

(*) Due too bloom filter false positive an extra round trip could be needed to re-request missing txs. According to wikipedia and the test we made false positive probability is equal or less of 1%

 

[Domrada]

Is there somewhere I can read a concise summary of this deceit and sleight of hand, manipulation, bullying, and censorship by core developers?

I currently find myself mostly supporting most of the core developers but am quite willing to change my mind in the face of compelling evidence.

Dooglus, keep seeking the truth. You'll get there. The core team and certain mining pool operators are cooperating to turn block space into a commodity that can only be obtained wholesale. We are on a path towards a future in which if you want to get your transactions into the blockchain, you'll have to use a service provider that bought the block space wholesale from a mining pool operator. If you want evidence, just look at how BTCC is prioritizing their transactions (they have confessed this publicly).

 

[freetrader]

When you blend the value discussion in technical solutions, it becomes complicated

It does, but you mentioned "inflation like QE" and

Notice that bitcoin's value is supported mostly by purchasing from those who don't have bitcoin, not who have

both of which are value discussions, the latter resting on a highly speculative point.

I think you raised a very good point about the majority preference for short term gains.
[doublepost=1461074198][/doublepost]

Who is this brg444? I remember it from trolltalk where he was very vocal about sidechain benefits...

Essentially a telemarketer who works for a Quebec company specializing in the "management of customer communications". They offer "four integrated business solutions: telephone management, social media management, management of chat and email management".

Given how much time he spends on the Bitcoin subject across various social media, you might be forgiven to think that he is being employed to do that.

 

[cypherdoc]

Dooglus, keep seeking the truth. You'll get there. The core team and certain mining pool operators are cooperating to turn block space into a commodity that can only be obtained wholesale. We are on a path towards a future in which if you want to get your transactions into the blockchain, you'll have to use a service provider that bought the block space wholesale from a mining pool operator. If you want evidence, just look at how BTCC is prioritizing their transactions (they have confessed this publicly).

great point.

it's sickening to see how COO Samson Mow conducts himself on Twitter.
[doublepost=1461074611][/doublepost]

 

[Dusty]

so it seems to me that Xthin is almost equivalent to RN because txs already present in node A mempool are not retransmitted again (*).

That's nice! I'm sorry I didn't take the time to read the BUIP.
Anyway, I find it less than optimal compared to the RL because there is one more roundtrip (the initial one where the peer sends his bloomfilter), and also because the peer sending the block has to prepare the block after receiving the bloom filter. If there are thousand of transactions to check, that could take a while, and every second of computation is a big hit on the latency. Also, this adhoc-operation must be executed for every peer (and you can have hundreds of them).
On the other side, the RL keep an updated list of the txs for each peer, so when it broadcasts a block it does not need to wait for the request roundtrip and the validation of the bloom filter.
Much faster, at a (non negligible) cost of more used memory.

 

[bitsko]

http://i.imgur.com/3yP1xk5.jpg

 

[cypherdoc]

That's nice! I'm sorry I didn't take the time to read the BUIP.
Anyway, I find it less than optimal compared to the RL because there is one more roundtrip (the initial one where the peer sends his bloomfilter), and also because the peer sending the block has to prepare the block after receiving the bloom filter. If there are thousand of transactions to check, that could take a while, and every second of computation is a big hit on the latency. Also, this adhoc-operation must be executed for every peer (and you can have hundreds of them).
On the other side, the RL keep an updated list of the txs for each peer, so when it broadcasts a block it does not need to wait for the request roundtrip and the validation of the bloom filter.
Much faster, at a (non negligible) cost of more used memory.

you should look at the graphs from @Peter Tschipper showing the BW cuts as a result of XThins. it's like 90%.

 

[Dusty]

you should look at the graphs from @Peter Tschipper showing the BW cuts as a result of XThins. it's like 90%.

I know xthin bandwidth is great. I was making a point about latency.
The final goal of fast block relay is not (only) to save bandwidth, but ultimately to have the new block as soon as possible.
If you have a high bandwidth connection it may happen that receiving a somewhat bigger block immediately is faster than, say, receiving a smaller block but after a few seconds due to various kind of latencies.
Since the RL uses a scheme where the peer knows in advance which tx a peer has, it may prepare a special crafted thin-block before receiving the invite with the bloom filter from the peer, and that is a plus on latency.
If the saved time makes a difference, that I can't say, but I suppose it gets bigger and bigger with an increased block size.

 

[sickpig]

(paging @Peter Tschipper, he's way more knowledgable than me on this subject)

Anyway, I find it less than optimal compared to the RL because there is one more roundtrip (the initial one where the peer sends his bloomfilter)

So you're saying that if a node use the RN client it does not need to require new blocks, it will receive blocks as soon they appear because the RN is going to broadcast them?

and also because the peer sending the block has to prepare the block after receiving the bloom filter.
If there are thousand of transactions to check, that could take a while, and every second of computation is a big hit on the latency. Also, this adhoc-operation must be executed for every peer (and you can have hundreds of them).
On the other side, the RL keep an updated list of the txs for each peer, so when it broadcasts a block it does not need to wait for the request roundtrip and the validation of the bloom filter.
Much faster, at a (non negligible) cost of more used memory.

fwiw this is a summary of processing/propagation time for an avg block received by a BU node of mine (blk hash is 000000000000000005dcc3bca3591ea6ea0e6a484997cbd96785bf1714a38da8, abbreviated to 0000...a38da8 for brevity in the log)


sickpig@BUNODE:~$ grep 000...a38da8 .bitcoin/debug.log
2016-04-19 12:39:29 Requesting Thinblock 000...a38da8 from peer 104.155.10.190:8333 (342875)
2016-04-19 12:39:29 Received thinblock 000...a38da8 from peer 104.155.10.190:8333 (342875). Size 1652 bytes.
2016-04-19 12:39:29 Reassembled thin block for 000...a38da8 (104926 bytes). Message was 1652 bytes, compression ratio 63.51
2016-04-19 12:39:29 Received block 000...a38da8 in 0.48 seconds
2016-04-19 12:39:29 UpdateTip: new best=000...a38da8 height=407993 log2_work=84.514161 tx=123394864 date=2016-04-19 12:39:44 progress=1.000000 cache=45.7MiB(17890tx)
2016-04-19 12:39:29 Processed Block 000...a38da8 in 0.07 seconds

So as you can see from requesting the block to fully validating it it took less than a second, 0.48 + 0.07 = 0.55 sec to be precise.

update: as @Peter Tschipper already said on reddit, Xthin+Xvalidate and all other thing already in the pipe, have the reduction of propagation time as main goal. The reduction of bandwidth it's a only a mean to achieve such a goal.

 

[Aquent]

proslogion
4:47 PM part of my part-time job is talking to people about Bitcoin
4:47
that's one reason why i am always here

https://bitcoincore.slack.com/archives/watercooler/p1460994463000764

What does he mean? Someone pays him to spend his time on bitcoin chatrooms?

And that brg guy, he apparently has some office job, but is always on chatting during office hours and chasing away potential bitcoin newcomers: https://files.slack.com/files-pri/T0J422BCZ-F11HD3SEN/pasted_image_at_2016_04_18_10_25_am.png

Weird to say the least.

Anyway, up to the miners now I guess whether they'd like to risk going into the halving with a capped capacity: https://www.reddit.com/r/btc/comments/4fhwpn/bitcoin_miners_and_industry_meet_in_beijing/ some nice info there.

Or whether they'll see everyone is in agreement. The question is in regards to an irrelevant detail of timing, and really, whether maxblocksize or segwit first (well segwit isn't ready), especially as everyone agrees on both, doesn't concern anyone else, but the miners and their mining business.

Bitcoin is based on miner's self interest, not anonymous reddit user's self interest. Especially as bots and sockpupets can easily create sybil. So, when everyone is agreed on maxblocksize, segwit and LN, I don't see why anyone would care which goes first since they all will be deployed.

I guess we'll see though whether people are more interested in stroking divisions, or providing solutions.

 

[cypherdoc]

I know xthin bandwidth is great. I was making a point about latency.
The final goal of fast block relay is not (only) to save bandwidth, but ultimately to have the new block as soon as possible.
If you have a high bandwidth connection it may happen that receiving a somewhat bigger block immediately is faster than, say, receiving a smaller block but after a few seconds due to various kind of latencies.
Since the RL uses a scheme where the peer knows in advance which tx a peer has, it may prepare a special crafted thin-block before receiving the invite with the bloom filter from the peer, and that is a plus on latency.
If the saved time makes a difference, that I can't say, but I suppose it gets bigger and bigger with an increased block size.

XThins eliminates the "burstiness" of announcing a new block which cuts transmission time and helps reduce the "centralization" argument.