Re: [bitcoin-dev] A new payment address format for segregated witness or not?

2015-12-21 Thread Tier Nolan via bitcoin-dev
On Mon, Dec 21, 2015 at 5:14 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The SW in P2SH is worse in terms of:
> 1. It requires an additional push in scriptSig, which is not prunable in
> transmission, and is counted as part of the core block size
>

"Prunable in transmission" means that you have to include it when not
sending the witnesses?

That is a name collision with UTXO set prunable.  My initial thought when
reading that was "but scriptSigs are inherently prunable, it is
scriptPubKeys that have to be held in the UTXO database" until I saw the
"in transmission" clarification.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] We need to fix the block withholding attack

2015-12-21 Thread Jannes Faber via bitcoin-dev
If you're saying a block withholding attack is a nice weapon to have to
dissuade large pools, isn't that easily defeated by large pools simply
masquerading as multiple small pools? As, for all we know, ghash may have
done?

If you don't know who to attack there's no point in having the weapon.
While that weapon is still dangerous in the hands of others that are
indiscriminate, like the solo miners example of Peter Todd.

Sorry if i misunderstood your point.

--
Jannes

On 20 December 2015 at 18:00, Emin Gün Sirer <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd  wrote:
>
>> There are a number of techniques that can be used to detect block
>> withholding attacks that you are not aware of. These techniques usually
>> have the characteristic that if known they can be avoided, so obviously
>> those who know about them are highly reluctant to reveal what exactly
>> they are. I personally know about some of them and have been asked to
>> keep that information secret, which I will.
>>
>
> Indeed, there are lots of weak measures that one could employ against
> an uninformed attacker. As I mentioned before, these are unlikely to be
> effective against a savvy attacker, and this is a good thing.
>
>
>> In the context of KYC, this techniques would likely hold up in court,
>> which means that if this stuff becomes a more serious problem it's
>> perfectly viable for large, well-resourced, pools to prevent block
>> withholding attacks, in part by removing anonymity of hashing power.
>> This would not be a positive development for the ecosystem.
>>
>
> KYC has a particular financial-regulation connotation in Bitcoin circles,
> of which I'm sure you're aware, and which you're using as a spectre.
> You don't mean government-regulated-KYC a la FINCEN and Bitcoin
> exchanges like Coinbase, you are just referring to a pool operator
> demanding to know that its customer is not coming from its competitors'
> data centers.
>
> And your prediction doesn't seem well-motivated or properly justified.
> There are tons of conditionals in your prediction, starting with the
> premise
> that every single open pool would implement some notion of identity
> checking. I don't believe that will happen. Instead, we will have the
> bigger
> pools become more suspicious of signing up new hash power, which is a
> good thing. And we will have small groups of people who have some reason
> for trusting each other (e.g. they know each other from IRC, conferences,
> etc) band together into small pools. These are fantastic outcomes for
> decentralization.
>
> Secondly, DRM tech can also easily be used to prevent block withholding
>> attacks by attesting to the honest of the hashing power. This is being
>> discussed in the industry, and again, this isn't a positive development
>> for the ecosystem.
>>
>
> DRM is a terrible application. Once again, I see that you're trying to use
> those
> three letters as a spectre as well, knowing that most people hate DRM, but
> keep in mind that DRM is just an application -- it's like pointing to
> Adobe Flash
> to taint all browser plugins.
>
> The tech behind DRM is called "attestation," and it provides a technical
> capability not possible by any other means. In essence, attestation can
> ensure that
> a remote node is indeed running the code that it purports to be running.
> Since
> most problems in computer security and distributed systems stem from not
> knowing what protocol the attacker is going to follow, attestation is the
> only
> technology we have that lets us step around this limitation.
>
> It can ensure, for instance,
>   - that a node purporting to be Bitcoin Core (vLatest) is indeed running
> an
> unadulterated, latest version of Bitcoin Core
>   - that a node claiming that it does not harvest IP addresses from SPV
> clients indeed does not harvest IP addresses.
>   - that a cloud hashing outfit that rented out X terahashes to a user did
> indeed rent out X terahashes to that particular user,
>   - that a miner operating on behalf of some pool P will not misbehave and
> discard perfectly good blocks
> and so forth. All of these would be great for the ecosystem. Just getting
> rid
> of the cloudhashing scams would put an end to a lot of heartache.
>
> > Keep in mind that when an open pool gets big, like GHash did and
>> > two other pools did before them, the only thing at our disposal used
>> > to be to yell at people about centralization until they left the big
>> > pools and reformed into smaller groups. Not only was such yelling
>> > kind of desperate looking, it wasn't incredibly effective, either.
>> > We had no protocol mechanisms that put pressure on big pools to
>> > stop signing up people. Ittay's discovery changed that: pools that
>> > get to be very big by indiscriminately signing up miners are likely to
>> > be infiltrated and their profitability will drop. And Peter's post is
>> > evidence that this is, indeed, happening as predicted. This i

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

2015-12-21 Thread Jorge Timón via bitcoin-dev
To clarify, although I have defended the deployment of segwit as a
hardfork, I have no strong opinion on whether to do that or do it as a
softfork first and then do a hardfork to move things out of the
coinbase to a better place.
I have a strong opinion against never doing the later hardfork though.
I would have supported segwit for Bitcoin even if it was only possible
as a hardfork, but there's a softfork version and that will hopefully
accelerate its deployment.
Since the plan seems to be to do a softfork first and a hardfork
moving the witness tree (and probably more things) outside of the
coinbase later, I support the plan for segwit deployment.
In fact, the plan is very exciting to me.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

2015-12-21 Thread Anthony Towns via bitcoin-dev
On Mon, Dec 21, 2015 at 05:21:55AM +, Btc Drak via bitcoin-dev wrote:
> On Mon, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev <
> > So I'd like to ask the community that we work towards this plan, as it
> > allows to make progress without being forced to make a possibly divisive
> > choice for one hardfork or another yet.
> Thank you for saying this. I also think the plan is solid and delivers
> multiple benefits without being contentious. The number of wins are so
> numerous, it's frankly a no-brainer.

+1's are off-topic, but... +1. My impression is that each of libsecp256k1,
versionbits, segregated witness, IBLT, weak blocks, and OP_CSV have
been demonstrated to be significant improvements that are implementable,
and don't introduce any new attacks or risks [0]. There's some freaking
awesome engineering that's gone into all of those.

> I guess the next step for segwit is a BIP and deployment on a testnet?

I think the following proposed features are as yet missing from Pieter's
segwit branch, and I'm guessing patches for them would be appreciated:

 - enforcing the proposed base+witness/4 < 1MB calculation
 - applying limits to sigops seen in witness signatures

I guess there might be other things that still need to be implemented
as well (and presumably bugs of course)?

I think I'm convinced that the proposed plan is the best approach (as
opposed to separate base<1MB, witness<3MB limits, or done as a hard fork,
or without committing to a merkle head for the witnesses, eg), though.

jl2012 already pointed to a draft segwit BIP in another thread, repeated
here though:

 https://github.com/jl2012/bips/blob/segwit/bip-segwit.mediawiki

Cheers,
aj (hoping that was enough content after the +1 to not get modded ;)

[0] I'm still not persuaded that even a small increase in blocksize
doesn't introduce unacceptable risks (frankly, I'm not entirely
persuaded the *current* limits don't have unacceptable risk) and that
frustrates me no end. But I guess (even after six months of reading
arguments about it!) I'm equally unpersuaded that there's actually
more to the intense desire for more blocksize is anything other than
fear/uncertainty/doubt mixed with a desire for transactions to be
effectively free, rather than costing even a few cents each... So,
personally, since the above doesn't really resolve that quandry
for me, it doesn't really resolve the blocksize debate for me
either. YMMV.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev