Do you guys think March 2016 is a bit late? I do.
Maybe we could divert the discussion to 'when should the 20 mb fork be done', like it sometimes works with children: "Do you want daddy to brush your teeth or would you rather want mommy to do it?"
Topic: Gold collapsing. Bitcoin UP. - page 379. (Read 2032266 times)
Hi, we started a market on the question wether or not the block size will be increased by 2016.
https://www.fairlay.com/event/category/bitcoin/blockchain/all/
Currently the likelihood is only around 10%. Thant means on the other side that you get about 10 times your money back if you predict on the increase and it actually happens.
https://www.fairlay.com/event/category/bitcoin/blockchain/all/
Currently the likelihood is only around 10%. Thant means on the other side that you get about 10 times your money back if you predict on the increase and it actually happens.
wow, thanks so much for this. there are no other Bitcoin devs i trust more than Alan & Gavin. he's helped me immensely over the years as i was one of the only two to donate $500 (top level) to his initial Armory crowdfunding campaign what, 3-4 yrs ago now? for that, i got an Armory USB stick, a teeshirt, a coupla bitcoins (i think), & most importantly his old laptop with a sticker on the back with his name and phone #'s, lol. i'm quite sure he forgot to remove them and i've only ever used the # twice 
he's taught me alot about crypto. i've tried to tailor back my contact with him in the last year or so as i know he is way busier than ever and has grown in stature so it didn't even occur to me to ask his opinion on this matter. best thing about him is he's a great guy. i'm so glad you did and hearing his response is reassuring to me that i am pushing the right direction. thanks again.
he's taught me alot about crypto. i've tried to tailor back my contact with him in the last year or so as i know he is way busier than ever and has grown in stature so it didn't even occur to me to ask his opinion on this matter. best thing about him is he's a great guy. i'm so glad you did and hearing his response is reassuring to me that i am pushing the right direction. thanks again.A pleasure, and snap! I donated $500 to Armory dev as well, but it was easier with BTC at $800+ :-)
BTW. the quote is from sourceforge, not a personal communication...
Similarly if Bob correctly handles the received notification transactions he can be confident that he can not be tied to the payment channel.
Everybody should dispose of their notification transactions via dust-be-gone, but regardless the number of transactions that have been sent to a notification address is publicly visible.What's not visible is who sent them, and whether they are real or not.
Let's say for example I am a Snowden sympathizer and the government has outlawed payments to Snowden and the government also suspects that I might want to illegally give Snowden payments. In such an environment identifying the creation of a payment channel to Snowden might be enough for the government to determine guilt, regardless of whether or not they identified the actual payments. So if they knew my payment code and Snowden's payment code, could scanning the blockchain history result in identifying the payment channel (not the actual payments).
I understand this situation is a bit of a reach, just trying to understand it though.
An observer will see that Snowden received a payment code, but they won't be able to read whose payment code it is.I understand this situation is a bit of a reach, just trying to understand it though.
The only way they learn it was you who set up the channel is if they have some other way to trace the coins you used to do it. A good client would be sure to use mixed coins for notification transactions.
OK I think I got it.
So both parties can individually control their anonymity then. If Alice only uses mixed coins for a notification transaction she can be confident that she can not be tied to the payment channel. Similarly if Bob correctly handles the received notification transactions he can be confident that he can not be tied to the payment channel.
Thanks for the explaination
When asked if that behavior was typical of OTC IPOs he stated that it was, but only for successful offerings.
“Yeah, new successful offerings. Many simply go down after the first day. Compare it to the first three days of any recent tech IPOs and you should see a similar pattern.”
http://www.miningpool.co.uk/gbtc-trading-explodes-order-book-gap-narrowing/
“Yeah, new successful offerings. Many simply go down after the first day. Compare it to the first three days of any recent tech IPOs and you should see a similar pattern.”
http://www.miningpool.co.uk/gbtc-trading-explodes-order-book-gap-narrowing/
Let's say for example I am a Snowden sympathizer and the government has outlawed payments to Snowden and the government also suspects that I might want to illegally give Snowden payments. In such an environment identifying the creation of a payment channel to Snowden might be enough for the government to determine guilt, regardless of whether or not they identified the actual payments. So if they knew my payment code and Snowden's payment code, could scanning the blockchain history result in identifying the payment channel (not the actual payments).
I understand this situation is a bit of a reach, just trying to understand it though.
An observer will see that Snowden received a payment code, but they won't be able to read whose payment code it is.I understand this situation is a bit of a reach, just trying to understand it though.
The only way they learn it was you who set up the channel is if they have some other way to trace the coins you used to do it. A good client would be sure to use mixed coins for notification transactions.
Both Alice's and Bob's payment codes are known since they are public and in addition the time frame of the notification transaction is also known. Couldn't such an agency then look for all transactions in that specific time frame that might be a notification transaction and try them until finding one that matches? Does such an attack gain information for Eve, or are there reasons this isn't possible or useful?
If an attacker already expects Alice and Bob to transact, then seeing a notification transaction doesn't tell them much. The attacker won't be able to connect the notification transaction with the actual payments.See: https://www.reddit.com/r/Bitcoin/comments/34prd6/i_made_a_3d_printed_stainless_steel_bitcoin/cqy16lr
Quote
If an attacker knows that certain UTXOs are associated with a particular individual (Bob), and if the attacker then sees those outputs used as inputs to a transaction which creates an output at a known notification address (Alice's), then the attacker can assume a probability that the Bob will send some bitcoins to Alice at some point in the future.
Bob might have sent a decoy notification to Alice, so the attacker can never be sure. All the attacker knows that Bob will sent Alice somewhere between 0 and 232 payments to Alice between the time of the notification transaction and forever.
The attacker might assume that any payments appearing in the mempool immediately following the notification transaction are a payment between Bob and Alice, but that's a problem that tends to solve itself as the transaction rate increases and can be addressed by intelligent clients which make sure to put a random amount of temporal separation between the notification transaction and the first payment.
Bob might have sent a decoy notification to Alice, so the attacker can never be sure. All the attacker knows that Bob will sent Alice somewhere between 0 and 232 payments to Alice between the time of the notification transaction and forever.
The attacker might assume that any payments appearing in the mempool immediately following the notification transaction are a payment between Bob and Alice, but that's a problem that tends to solve itself as the transaction rate increases and can be addressed by intelligent clients which make sure to put a random amount of temporal separation between the notification transaction and the first payment.
OK, thanks that helps. So this is saying that the only knowledge gained is that Bob and Alice setup a payment connection, but even with that an attacker couldn't identify what payments happened in the future (or even if any payments happened at all for that matter). So if Bob inadvertently used the notification payments incorrectly, the only information lost is that a payment channel was established between Alice and Bob. Is that right?
If an attacker already expects Alice and Bob to transact, then seeing a notification transaction doesn't tell them much.
I'm not 100% sure on this.
Let's say for example I am a Snowden sympathizer and the government has outlawed payments to Snowden and the government also suspects that I might want to illegally give Snowden payments. In such an environment identifying the creation of a payment channel to Snowden might be enough for the government to determine guilt, regardless of whether or not they identified the actual payments. So if they knew my payment code and Snowden's payment code, could scanning the blockchain history result in identifying the payment channel (not the actual payments).
I understand this situation is a bit of a reach, just trying to understand it though.
there is no doubt in my mind that THIS is the very chart, $DJT, some very powerful players are watching and seeking to stick save. or, yes, they could also just be powerful dip buyers of the weakest index around but my pt stands. this is the chart to watch. i count no less than 8 tests of the support line as drawn with someone intervening every single time to prevent a plunge (or dip buy). their problem is, each bounce keeps getting weaker and weaker and we have a non-confirmation on the board:
on a more general level, this is great news:
While the court didn’t reach the crucial question of whether the program violates the Fourth Amendment, the ruling gives civil libertarians good reason to hope that a massive and egregious violation of every American’s privacy will finally come to an end.
http://www.cato.org/blog/second-circuit-declares-nsas-telephone-dragnet-unlawful
While the court didn’t reach the crucial question of whether the program violates the Fourth Amendment, the ruling gives civil libertarians good reason to hope that a massive and egregious violation of every American’s privacy will finally come to an end.
http://www.cato.org/blog/second-circuit-declares-nsas-telephone-dragnet-unlawful
notice the MACD turning up strongly. remember that bear mkts turn on bad news. bad in the sense of extreme controversy over Gavin's proposal and seeming chaos of opinion in the Bitcoin community:
Both Alice's and Bob's payment codes are known since they are public and in addition the time frame of the notification transaction is also known. Couldn't such an agency then look for all transactions in that specific time frame that might be a notification transaction and try them until finding one that matches? Does such an attack gain information for Eve, or are there reasons this isn't possible or useful?
If an attacker already expects Alice and Bob to transact, then seeing a notification transaction doesn't tell them much. The attacker won't be able to connect the notification transaction with the actual payments.See: https://www.reddit.com/r/Bitcoin/comments/34prd6/i_made_a_3d_printed_stainless_steel_bitcoin/cqy16lr
Quote
If an attacker knows that certain UTXOs are associated with a particular individual (Bob), and if the attacker then sees those outputs used as inputs to a transaction which creates an output at a known notification address (Alice's), then the attacker can assume a probability that the Bob will send some bitcoins to Alice at some point in the future.
Bob might have sent a decoy notification to Alice, so the attacker can never be sure. All the attacker knows that Bob will sent Alice somewhere between 0 and 232 payments to Alice between the time of the notification transaction and forever.
The attacker might assume that any payments appearing in the mempool immediately following the notification transaction are a payment between Bob and Alice, but that's a problem that tends to solve itself as the transaction rate increases and can be addressed by intelligent clients which make sure to put a random amount of temporal separation between the notification transaction and the first payment.
Bob might have sent a decoy notification to Alice, so the attacker can never be sure. All the attacker knows that Bob will sent Alice somewhere between 0 and 232 payments to Alice between the time of the notification transaction and forever.
The attacker might assume that any payments appearing in the mempool immediately following the notification transaction are a payment between Bob and Alice, but that's a problem that tends to solve itself as the transaction rate increases and can be addressed by intelligent clients which make sure to put a random amount of temporal separation between the notification transaction and the first payment.
Alan Reiner (Armory lead developer) weighs in and clearly shows that he understands the Big Picture.
What he writes deserves to be memorialized here as it is pertinent to the whole spirit of "Gold collapsing. Bitcoin UP"
Quoted text below
This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this. I have heard Gavin's talks on increasing
the block size, and the two most persuasive points to me were:
(1) Blocks are essentially nearing "full" now. And by "full" he means
that the reliability of the network (from the average user perspective)
is about to be impacted in a very negative way (I believe it was due to
the inconsistent time between blocks). I think Gavin said that his
simulations showed 400 kB - 600 kB worth of transactions per 10 min
(approx 3-4 tps) is where things start to behave poorly for certain
classes of transactions. In other words, we're very close to the
effective limit in terms of maintaining the current "standard of
living", and with a year needed to raise the block time this actually is
urgent.
(2) Leveraging fee pressure at 1MB to solve the problem is actually
really a bad idea. It's really bad while Bitcoin is still growing, and
relying on fee pressure at 1 MB severely impacts attractiveness and
adoption potential of Bitcoin (due to high fees and unreliability). But
more importantly, it ignores the fact that for a 7 tps is pathetic for a
global transaction system. It is a couple orders of magnitude too low
for any meaningful commercial activity to occur. If we continue with a
cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to
be useful for the vast majority of the world (which probably leads to
failure). We shouldn't be talking about fee pressure until we hit 700
tps, which is probably still too low.
You can argue that side chains and payment channels could alleviate
this. But how far off are they? We're going to hit effective 1MB
limits long before we can leverage those in a meaningful way. Even if
everyone used them, getting a billion people onto the system just can't
happen even at 1 transaction per year per person to get into a payment
channel or move money between side chains.
We get asked all the time by corporate clients about scalability. A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they expect it handle. We always assure them that 7 tps
is not the final answer.
Satoshi didn't believe 1 MB blocks were the correct answer. I
personally think this is critical to Bitcoin's long term future. And
I'm not sure what else Gavin could've done to push this along in a
meaninful way.
-Alan
What he writes deserves to be memorialized here as it is pertinent to the whole spirit of "Gold collapsing. Bitcoin UP"
Quoted text below
This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this. I have heard Gavin's talks on increasing
the block size, and the two most persuasive points to me were:
(1) Blocks are essentially nearing "full" now. And by "full" he means
that the reliability of the network (from the average user perspective)
is about to be impacted in a very negative way (I believe it was due to
the inconsistent time between blocks). I think Gavin said that his
simulations showed 400 kB - 600 kB worth of transactions per 10 min
(approx 3-4 tps) is where things start to behave poorly for certain
classes of transactions. In other words, we're very close to the
effective limit in terms of maintaining the current "standard of
living", and with a year needed to raise the block time this actually is
urgent.
(2) Leveraging fee pressure at 1MB to solve the problem is actually
really a bad idea. It's really bad while Bitcoin is still growing, and
relying on fee pressure at 1 MB severely impacts attractiveness and
adoption potential of Bitcoin (due to high fees and unreliability). But
more importantly, it ignores the fact that for a 7 tps is pathetic for a
global transaction system. It is a couple orders of magnitude too low
for any meaningful commercial activity to occur. If we continue with a
cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to
be useful for the vast majority of the world (which probably leads to
failure). We shouldn't be talking about fee pressure until we hit 700
tps, which is probably still too low.
You can argue that side chains and payment channels could alleviate
this. But how far off are they? We're going to hit effective 1MB
limits long before we can leverage those in a meaningful way. Even if
everyone used them, getting a billion people onto the system just can't
happen even at 1 transaction per year per person to get into a payment
channel or move money between side chains.
We get asked all the time by corporate clients about scalability. A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they expect it handle. We always assure them that 7 tps
is not the final answer.
Satoshi didn't believe 1 MB blocks were the correct answer. I
personally think this is critical to Bitcoin's long term future. And
I'm not sure what else Gavin could've done to push this along in a
meaninful way.
-Alan
wow, thanks so much for this. there are no other Bitcoin devs i trust more than Alan & Gavin. he's helped me immensely over the years as i was one of the only two to donate $500 (top level) to his initial Armory crowdfunding campaign what, 3-4 yrs ago now? for that, i got an Armory USB stick, a teeshirt, a coupla bitcoins (i think), & most importantly his old laptop with a sticker on the back with his name and phone #'s, lol. i'm quite sure he forgot to remove them and i've only ever used the # twice
he's taught me alot about crypto. i've tried to tailor back my contact with him in the last year or so as i know he is way busier than ever and has grown in stature so it didn't even occur to me to ask his opinion on this matter. best thing about him is he's a great guy. i'm so glad you did and hearing his response is reassuring to me that i am pushing the right direction. thanks again. Added some diagrams which should greatly enhance understanding of the protocol:
https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
Thanks for the diagrams, they were helpful.
Quick question. If I understand the notification transaction correctly, in order to maintain privacy on future payments, payments to the notification address can not be associated with Bob's payment code, and so Bob has to make sure that payments to this notification address are never associated with him. And if they were then the privacy is lost.
If this is the case (and I may be wrong) I was wondering about potential attacks here. For example are timing attacks possible? i.e. imagine the situation where a government agency monitoring the internet knows that Alice intended to initiate a payment to Bob for an online purchase at exactly 8:52pm.
Both Alice's and Bob's payment codes are known since they are public and in addition the time frame of the notification transaction is also known. Couldn't such an agency then look for all transactions in that specific time frame that might be a notification transaction and try them until finding one that matches? Does such an attack gain information for Eve, or are there reasons this isn't possible or useful?
Alan Reiner (Armory lead developer) weighs in and clearly shows that he understands the Big Picture.
What he writes deserves to be memorialized here as it is pertinent to the whole spirit of "Gold collapsing. Bitcoin UP"
Quoted text below
This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this. I have heard Gavin's talks on increasing
the block size, and the two most persuasive points to me were:
(1) Blocks are essentially nearing "full" now. And by "full" he means
that the reliability of the network (from the average user perspective)
is about to be impacted in a very negative way (I believe it was due to
the inconsistent time between blocks). I think Gavin said that his
simulations showed 400 kB - 600 kB worth of transactions per 10 min
(approx 3-4 tps) is where things start to behave poorly for certain
classes of transactions. In other words, we're very close to the
effective limit in terms of maintaining the current "standard of
living", and with a year needed to raise the block time this actually is
urgent.
(2) Leveraging fee pressure at 1MB to solve the problem is actually
really a bad idea. It's really bad while Bitcoin is still growing, and
relying on fee pressure at 1 MB severely impacts attractiveness and
adoption potential of Bitcoin (due to high fees and unreliability). But
more importantly, it ignores the fact that for a 7 tps is pathetic for a
global transaction system. It is a couple orders of magnitude too low
for any meaningful commercial activity to occur. If we continue with a
cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to
be useful for the vast majority of the world (which probably leads to
failure). We shouldn't be talking about fee pressure until we hit 700
tps, which is probably still too low.
You can argue that side chains and payment channels could alleviate
this. But how far off are they? We're going to hit effective 1MB
limits long before we can leverage those in a meaningful way. Even if
everyone used them, getting a billion people onto the system just can't
happen even at 1 transaction per year per person to get into a payment
channel or move money between side chains.
We get asked all the time by corporate clients about scalability. A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they expect it handle. We always assure them that 7 tps
is not the final answer.
Satoshi didn't believe 1 MB blocks were the correct answer. I
personally think this is critical to Bitcoin's long term future. And
I'm not sure what else Gavin could've done to push this along in a
meaninful way.
-Alan
What he writes deserves to be memorialized here as it is pertinent to the whole spirit of "Gold collapsing. Bitcoin UP"
Quoted text below
This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this. I have heard Gavin's talks on increasing
the block size, and the two most persuasive points to me were:
(1) Blocks are essentially nearing "full" now. And by "full" he means
that the reliability of the network (from the average user perspective)
is about to be impacted in a very negative way (I believe it was due to
the inconsistent time between blocks). I think Gavin said that his
simulations showed 400 kB - 600 kB worth of transactions per 10 min
(approx 3-4 tps) is where things start to behave poorly for certain
classes of transactions. In other words, we're very close to the
effective limit in terms of maintaining the current "standard of
living", and with a year needed to raise the block time this actually is
urgent.
(2) Leveraging fee pressure at 1MB to solve the problem is actually
really a bad idea. It's really bad while Bitcoin is still growing, and
relying on fee pressure at 1 MB severely impacts attractiveness and
adoption potential of Bitcoin (due to high fees and unreliability). But
more importantly, it ignores the fact that for a 7 tps is pathetic for a
global transaction system. It is a couple orders of magnitude too low
for any meaningful commercial activity to occur. If we continue with a
cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to
be useful for the vast majority of the world (which probably leads to
failure). We shouldn't be talking about fee pressure until we hit 700
tps, which is probably still too low.
You can argue that side chains and payment channels could alleviate
this. But how far off are they? We're going to hit effective 1MB
limits long before we can leverage those in a meaningful way. Even if
everyone used them, getting a billion people onto the system just can't
happen even at 1 transaction per year per person to get into a payment
channel or move money between side chains.
We get asked all the time by corporate clients about scalability. A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they expect it handle. We always assure them that 7 tps
is not the final answer.
Satoshi didn't believe 1 MB blocks were the correct answer. I
personally think this is critical to Bitcoin's long term future. And
I'm not sure what else Gavin could've done to push this along in a
meaninful way.
-Alan
Besides i dont really appreciate his pushy attitude and I fail to agree with his arguments (ie. his childish blog points and "kudos"), which are anything but technical btw.
Not that i am an "anti" blocksize fork forever either.
Anyway im just a regular bitcoiner, hoping it all goes for thebest greater good.
Not that i am an "anti" blocksize fork forever either.
Anyway im just a regular bitcoiner, hoping it all goes for the
IMO he is not being pushy enough. A lot can happen in the next 10 months. Tx rates could easily double, which would bump right up against the 1mb limit. Forget a 3x, 5x, or 10x increase.
Most likely there will be plenty of room for the block size increase AND secondary layer scaling solutions.
How do you think ordinary Bitcoin users would react on hearing of crashing nodes, a swelling transaction backlog, a sudden spike in double spending, skyrocketing fees … and all of it because of an entirely predictable event with an incredibly simple fix?
They would conclude that the Bitcoin developer community was incompetent. That would make the news.
They would conclude that the Bitcoin developer community was incompetent. That would make the news.
P2P don't react per futur anticipation ... that why P2P survive from 17 years now (in file sharing).
They see ... and ... they make correction.
We don't play like FED or BOJ or BCE ... with god prediction.
We wait ... see ... and make correction.
Like normal people.
normal ppl plan ahead too.
bit torrent can afford to take a wait and see attitude b/c it "only" involves sharing files, usually music, and is used by a small niche community. p2p has never before dealt with the network of money which depends largely on "confidence". Bitcoin can't afford to allow itself to be taken down only to get up again in a repetitive process. i'd argue that the community wants to spread Bitcoin far and wide to replace one of the biggest problems in the world today; fiat money. that can only happen with a growing level of confidence in a system that doesn't break down repetitively from choke points.
that type of strategy could set us back a hundred years.
can one of you tech guys comment on Peter Todds claim that there was an entire book embedded in the BC a month ago? how is it done?
https://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqystoo?context=3
https://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqystoo?context=3
Quote from: cypher on reddit https://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqz4la6
Is this a consequence of p2sh?
Yes, it is.
They used the 520 byte of the redeemScript to "inject" suitably padded text for easy recovery with strings(1) (i.e. strings -n 20).
"inject" suitably padded text for easy recovery with strings(1) (i.e. strings -n 20).
can you explain this a bit more and did this bloat the p2sh tx markedly? if it is such an effective attack, why aren't we seeing a whole slew of these occurring?
How do you think ordinary Bitcoin users would react on hearing of crashing nodes, a swelling transaction backlog, a sudden spike in double spending, skyrocketing fees … and all of it because of an entirely predictable event with an incredibly simple fix?
They would conclude that the Bitcoin developer community was incompetent. That would make the news.
They would conclude that the Bitcoin developer community was incompetent. That would make the news.
P2P don't react per futur anticipation ... that why P2P survive from 17 years now (in file sharing).
They see ... and ... they make correction.
We don't play like FED or BOJ or BCE ... with god prediction.
We wait ... see ... and make correction.
Like normal people.
Jump to: