Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

2017-04-07 Thread Jannes Faber via bitcoin-dev 
On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Ethically, this situation has some similarities to the DAO fork.
>
>
> Much better analogy:
>
> 1. An ISV make software which makes use of an undocumented OS feature.
> 2. That feature is no longer present in the next OS release.
> 3. ISV suffers losses because its software cannot work under new OS, and
> thus people stop buying it.
>
> I think 99% of programmers would agree that this loss was inflicted by a
> bad decision of ISV, and not by OS vendor changing OS internals. Relying on
> undocumented features is something you do on your own risk.
>

Right. And in this case, code still is law: if the code specifies a version
number field and some miner finds an optimization that only works when the
version number == 1 then it's his own problem once the network upgrades to
version 2. In no way is there anything ethical about blocking the upgrade.

History is not an indicator of the possible values any field can hold in
the future. Limiting your operation to some arbitrary subset is at your own
risk.

Regarding the comparison: I haven't heard anyone even suggest rolling back
the last year of the blockchain to undo the damage already done, any
comparison can end there. If Jonathan wants to persist with this comparison
it would be more like people deciding to stop further funding of the hacked
contract. Yeah, that evil.

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

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

2016-08-09 Thread Jannes Faber via bitcoin-dev 
Wow. No value judgement, but 1980 called, they want their radio broadcast
for analogue modems back. Both very cool and very cringe worthy.

It sounds quite horrible tbh. Imagine this being as pervasive as bar and qr
codes. And it's as meaningful and unpleasant to the human ear as a qr code
is to the eye.

Please think of something like using a Mozart symphony as the carrier wave
onto which you modulate your signal. Let the notes last a little longer to
represent a 1 bit. Or change the tempo. Or add an echo. Make it so the
listener can interpret it as a generic not too annoying tune and not even
realise it's different every time without being an audiophile.

Maybe have a 100 different base tunes from mozart to hiphop so the user can
pick one suitable to their audience and context. Maybe have some that don't
interfere with human speech frequencies so narrator can keep talking right
over it.

I guess it may be tricky because you want your signal to survive
re-encoding as increased playback speeds.

Another consideration: you want a preamble that is very easy to detect, so
it doesn't cost a lot of CPU (battery) to have your podcast player
continuously scanning for these things.

Not sure all these wishes are possible at the same time, but surely there's
research around on some?.

On 10 Aug 2016 1:28 a.m., "Daniel Hoffman via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and FLAC
> of both tone tables, first 16 then 4). Is this good enough to warrant an
> official BIP number? I haven't built a decoder yet, but it seems like the
> encoder is working properly (looked at Audacity, seems like it is working),
> and some people on reddit want to "allow for decoding experiments"
> 
>
> What suggestions do you all have for it?
>
> On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman  > wrote:
>
>> It wouldn't be feasible in the vast majority of cases, but I can't think
>> of a reason why it can't be built into the standard.
>>
>> On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Would it be feasible to transmit an entire BIP21 URI as audio? If you
>>> were to encode any extra information (such as amount), it would be useful
>>> to include a checksum for the entire message. This checksum could possibly
>>> be used instead of the checksum in the address.
>>>
>>> Trevin
>>>
>>> On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 Daniel,
Thanks for proposing this.  I think this could have some useful use
 cases as you state.  I was wondering what you would think to adding some
 additional tones to optionally denote an amount (in satoshis?).

 (FYI, actual link is here:  https://github.com/Dako300/BIP )

 Justin

 On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is my BIP idea: a fast, robust, and standardized for representing
> Bitcoin addresses over audio. It takes the binary representation of the
> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
> (depending on type, 2 bit only for low quality audio like american
> telephone lines), and generates a tone based upon that value. This started
> because I wanted an easy way to donate to podcasts that I listen to, and
> having a Shazam-esque app (or a media player with this capability) that
> gives me an address automatically would be wonderful for both the consumer
> and producer. Comes with error correction built into the protocol
>
> You can see the full specification of the BIP on my GitHub page (
> https://github.com/Dako300/BIP-0153).
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


 --

 Justin W. Newton
 Founder/CEO
 Netki, Inc.

 jus...@netki.com
 +1.818.261.4248



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


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

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-11 Thread Jannes Faber via bitcoin-dev 
On 11 May 2016 at 16:18, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Jorge Timón said..
> > What do you mean by "embrace" in the context of a patented optimization
> that one miner can prevent the rest from using?
>
> Everyone seems to assume that one ASIC manufacturer will get the advantage
> of AsicBoost while others won't. If a patent license is non-exclusive, then
> all can.
>
>

1. Whatever way you look at it, it will be an extra barrier of entry (cost,
legal hassle, more complex chip design) for any new ASIC manufacturer
trying to enter the market. That counters free competition and thus
decentralization.

2. Why would you want to put yourself in the central spot of the big
decider on who gets access to the technology (and therefore the whole
mining game) and who doesn't. You're not afraid of NSA knocking on your
door to politely hand you their blacklist? You don't think this counters
all the years of hard work that went into Bitcoin exactly to avoid any such
central points of authority?

P.S. I'm not decided yet on being for or against a HF to ban AsicBoost
myself, nor does my opinion count for much. But I think I do see real
problems, like the above.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-11 Thread Jannes Faber via bitcoin-dev 
On 11 May 2016 at 12:36, Henning Kopp  wrote:

> On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev
> wrote:
> > On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > There is no way to tell from a block if it was mined with AsicBoost or
> > > not. So you don’t know what percentage of the hashrate uses AsicBoost
> at
> > > any point in time. How can you risk forking that percentage out? Note
> that
> > > this would be a GUARANTEED chain fork. Meaning that after you change
> the
> > > block mining algorithm some percentage of hardware will no longer be
> able
> > > to produce valid blocks. That hardware cannot “switch over” to the
> majority
> > > chain even if it wanted to. Hence you are guaranteed to have two
> > > co-existing bitcoin blockchains afterwards.
> > >
> > > Again: this is unlike the hypothetical persistence of two chains after
> a
> > > hardfork that is only contentious but doesn’t change the mining
> algorithm,
> > > the kind of hardfork you are proposing would guarantee the persistence
> of
> > > two chains.
> > >
> >
> > Assuming AsicBoost miners are in the minority, their chain will
> constantly
> > get overtaken. So it will not be one endless hard fork as you claim, but
> > rather AsicBoost blocks will continue to be ignored (orphaned) until they
> > stop making them.
>
> At least until a difficulty adjustment on the AsicBoost chain takes
> place. From that point on, both chains, the AsicBoost one and the
> forked one will grow approximately at the same speed.
>
>
No: you are still assuming AsicBoost miners would reject normal blocks.
They don't now and they would have to specifically code for that as a reply
to AsicBoost being banned. So there won't be two chains at all, only the
main chain with a lot (more than usual) of short (few blocks) forks. Each
forks starts anew, it's not one long fork. Therefore there is no
"difficulty adjustment on the AiscBoost chain".

Now if they do decide to ban non-AsicBoost blocks as a response to being
banned themselves, they're just another altcoin with a different PoW and no
one would have a reason to use them over Bitcoin (apart from maybe selling
those forked coins asap).

You're confused about what "longest" means as well: it's not just the
number of blocks, it's the aggregate difficulty that counts: so AsicBoost
would never become "longer" (more total work) either.

Hope this helps clear things up.

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-11 Thread Jannes Faber via bitcoin-dev 
On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There is no way to tell from a block if it was mined with AsicBoost or
> not. So you don’t know what percentage of the hashrate uses AsicBoost at
> any point in time. How can you risk forking that percentage out? Note that
> this would be a GUARANTEED chain fork. Meaning that after you change the
> block mining algorithm some percentage of hardware will no longer be able
> to produce valid blocks. That hardware cannot “switch over” to the majority
> chain even if it wanted to. Hence you are guaranteed to have two
> co-existing bitcoin blockchains afterwards.
>
> Again: this is unlike the hypothetical persistence of two chains after a
> hardfork that is only contentious but doesn’t change the mining algorithm,
> the kind of hardfork you are proposing would guarantee the persistence of
> two chains.
>

Assuming AsicBoost miners are in the minority, their chain will constantly
get overtaken. So it will not be one endless hard fork as you claim, but
rather AsicBoost blocks will continue to be ignored (orphaned) until they
stop making them.

That hardware cannot “switch over” to the majority chain even if it wanted
> to.
>

They will in fact continually "switch over" to the majority, they just are
unable to extend that majority chain themselves.

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

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

2016-02-07 Thread Jannes Faber via bitcoin-dev 
On 6 Feb 2016 4:41 p.m., "Gavin Andresen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Responding to "28 days is not long enough" :
>
> I keep seeing this claim made with no evidence to back it up.  As I said,
I surveyed several of the biggest infrastructure providers and the btcd
lead developer and they all agree "28 days is plenty of time."

28 days doesn't sound like enough for exchanges and others holding 3rd
party coins. They will have to start untangling the Bitcoins from
classiccoins immediately, while pausing all withdrawals. They *must* be
able to send their customers both coins as separate withdrawals. If not,
that amounts to theft of their customers funds.

(Note that the above describes the honest exchanges. Imagine the dishonest
ones that simply steal the classiccoins from their customers and sell them
for their own profit.)

The only other option is guaranteeing customers both coins in one
transaction, which they can't.

Surely you can't expect small entities to start putting in massive man
hours into this even before the hard fork has been triggered? Or even big
entities to have all that implemented and tested within *20* working days?

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

[bitcoin-dev] Best (block nr % 2016) for hard fork activation?

2016-01-28 Thread Jannes Faber via bitcoin-dev 
Hi,

Question if you'll allow me. This is not about Gavin's latest hard fork
proposal but in general about any hard (or soft) fork.

I was surprised to see a period expressed in human time instead of in block
time:

> Blocks with timestamps greater than or equal to the triggering block's
timestamp plus 28 days (60*60*24*28 seconds) shall have the new limits.

But even more so I would expect there to be significant differences in
effects on non-updated clients depending on the moment (expressed as block
number) of applying the new rules. I see a few options, all relating to the
2016 blocks recalibration window.

1) the first block after difficulty adjustment.
2) the last block before the difficulty adjustment.
3) in the middle
4) n blocks before the adjustment with n the smallest number of blocks
calculated such that the adjustment can just manage to do the maximum
possible drop in difficulty.

One of the effects I'm thinking of would be in case of an evil contentious
75-25 hard fork. If that activates at 1) or 2) it will take an awful long
time for the 25% chain to get to 2016 for the next adjustment all the while
having 40 minutes block times. Option 4) sounds a lot better for the
conservative chain. The attacking fork clearly has a choice to make it as
hard as possible for them.

On the other hand when a non-contentious hard fork is rolled out, one could
argue that it's actually best for everyone if the remaining 1% chain
doesn't stand a chance of ever reaching 2016 blocks anymore (not even by a
decent sized attacker trying to double spend on stragglers). Also causing
all alarm bells to go off in the non-updated clients.

Have people thought through all the different scenarios yet?

And would it not make sense to define whatever the best choice is as
mandatory for any hard fork proposal? BIP9? (Realising attackers won't
necessarily follow BIPs anyway.)

Does something like this also play a role for soft forks?

I do realise that it's quite possible for the first few blocks, mined after
the new rules become valid, to still be old style blocks. Thus maybe
defeating the whole planning.
___
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-25 Thread Jannes Faber via bitcoin-dev 
On 25 Dec 2015 12:15 p.m., "Ittay"  wrote:

> As for masquerading as multiple small pools -- that's a very good point,
with a surprising answer: it doesn't really matter. An attacker attacks all
parts of the open pool proportionally to their size, and the result is
basically identical to that of attacking a single large pool.

While true, that's only relevant to the indiscriminate attacker! The
vigilante attacker that wants to hurt only pools that are too large,
doesn't even know that there's a need to attack as all of them seem small.

That's what i was saying.

>
> On Mon, Dec 21, 2015 at 1:39 PM, Jannes Faber via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> 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 secur

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] Segregated Witness features wish list

2015-12-11 Thread Jannes Faber via bitcoin-dev 
Segregated IBLT

I was just wondering if it would make sense when we have SW to also make
Segregated IBLT? Segregating transactions from signatures and then tune the
parameters such that transactions have a slightly higher guarantee and save
a bit of space on the signatures side.

IBLT should of course, most of the time, convey all transactions _and_ all
signatures. However, in suboptimal situations, at least the receiving miner
will be more likely to have all the transactions, just possibly not all the
signatures.

Assuming the miner was already planning on SPV mining anyway, at least now
she knows which transactions to remove from her mempool, taking away an
excuse to mine an empty block. And she can still verify most of the
signatures too (whatever % could be recovered from the IBLT).

I guess this does not improve the worst adversarial case for IBLT block
propagation, but it should improve the effectiveness in cases where the
"normal" IBLT would fail to deliver all transactions. Transactions without
signatures is better than no transactions at all, for a miner that's eager
to start on the next block, right? In "optimal" cases it would reduce the
size of the IBLT.

Sorry if this was already suggested.


--
Jannes

On 10 December 2015 at 13:54, Tamas Blummer via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Note that the unused space in coin base input script allows us to
> soft-fork an additional SW Merkle tree root into the design,
> therefore please make sure the new SW data structure also has a new slot
> for future extension.
>
> Tamas Blummer
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Blockchain verification flag (BIP draft)

2015-12-04 Thread Jannes Faber via bitcoin-dev 
1) (I would assume this is already current default behaviour, but just in
case.) Would it not make sense to *never* send a blockheader to an SPV
client unless the node itself fully validated that block? Regardless of who
mined the block and whether this verification flag has been set or not.

2) Besides having your verification flag in the block, would it not also
make sense to have such a flag in the P2P protocol when blocks (or headers)
are communicated? That way a node could simply do some quick sanity checks
(difficulty as anti-DOS) on an incoming block and then immediately
propagate it to the next (non-SPV) node, but with a flag "Looks good, but I
haven't fully validated it myself, so please don't blame me". And if the
block does turn out to be invalid, the node does not get banned if it was
honest about it.

3) With the above implemented, I can imagine miners running 2 (or more)
nodes side by side, one of them doesn't validate in order to reduce latency
and orphan rates, but the other one does validate and quickly signals the
first one if there's a problem. Both nodes don't necessarily need to be in
the same network or even on the same side of the Great Firewall. Of course
they would be whitelisting each other for trust, or the signal would need
to include some sort of proof.

This probably has been suggested many times already, sorry if this is a
dumb idea.

--
Jannes

On 4 December 2015 at 09:26, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> For discussion,
>
> A significant fraction of hashrate currently mines blocks without
> verifying them for a span of time after a new block shows up on the
> network for economically rational reasons. This otherwise harmful
> behavior can be made a beneficial to the whole network; but only if it
> is communicated.
>
> This BIP proposal suggests a communication channel and describes its
> use and the motivations for it.  I wrote it in response to suggestions
> that Bitcoin Core add explicit support for this kind of mining, which
> could also implement best in class risk mitigations. I believe
> signaling the behavior is a necessary component for risk mitigation
> here.
>
> -
>
> 
>   BIP: draft-maxwell-flagverify
>   Title: Blockchain verification flag
>   Author: Greg Maxwell 
>   Status: Draft
>   Type: Standards Track
>   Created: 2015-12-02
> 
>
> ==Abstract==
>
> This BIP describes a flag that the authors of blocks can use to voluntarily
> signal that they have completely validated the content of their
> block and the blocks before it.
>
> Correct use of this signaling is not enforced internally to the network
> but if used it can act as a hint allowing more intelligent risk analysis.
>
> If deployed and adhered to, this mechanism turns otherwise harmful
> validation skipping by miners into a behavior which benefits the public.
>
> ==Summary==
>
> The version field in a Bitcoin block header is a 32-bit signed integer.
>
> The most significant bit (30) of the block version is defined to signal
> that
> the author of the block has validated the whole chain up to and including
> the
> content of the block.
>
> Conforming miners MUST NOT set this flag when they have not completely
> validated the prior block(s) or the content of their own block.  Miners
> should continue to try to minimize the amount of time spent mining
> on a non-validated chain.  Blocks which extend an invalid chain will
> continue to be rejected and ultimately orphaned as validation catches up.
>
> It is recommended, but not required, that miners also not set the flag on
> blocks
> created by the same device which created the block immediately prior.  This
> will reduce the incorrect implication of independent validation when the
> two
> most recent blocks are both the product of the same, single, faulty system.
>
> The set state for the bit is defined as verified so that that
> un(der)maintained systems do not falsely signal validation.
>
> Non-verifying clients of the network may check this bit (e.g. checking
> that the version is >= 1073741824) and use it as an input to their risk
> modeling.  It is recommended that once this BIP is widely accepted by the
> network that non-full-node wallets refrain from counting confirmations on
> blocks where the bit is not set.
>
> The authors of non-verifying clients should keep in mind that this flag
> is only correct with the cooperation of the block author, and even then
> a validating miner may still accidentally accept or produce an invalid
> block due to faulty hardware or software.  Additionally, any miner which
> correctly uses this flag could stop doing so at any time, and might
> do so intentionally in order to increase the effectiveness of an attack.
> As a result of misunderstanding, misconfiguration, laziness, or other
> human factors some miners may falsely set the flag.  Because invalid
> blocks are rare it may take a long time to detec

Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"

2015-11-24 Thread Jannes Faber via bitcoin-dev 
Few issues I can think of:

1. In its basic form this encourages address reuse. Unless the wildcard can
be constructed such that it can match a whole branch of an HD  wallet.
Although I guess that would tie all those addresses together making HD moot
to begin with.

2. Sounds pretty dangerous during reorgs. Maybe such a transaction should
include a block height which indicates the maximum block that any utxo can
match. With the requirement that the specified block height is at least 100
blocks in the past. Maybe add a minimum block height as well to prevent
unnecessary scanning (with the requirement that at least one utxo must be
in that minimum block).

3. Seems like a nice way to the reduce utxo set. But hard to say how
effective it would really be.
On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > This idea could be applied by having the wildcard signature apply to all
> > UTXOs that are of a standard form and paid to a particular address, and
> be
> > a signature of some kind of message to that effect.
>
> I think this is true. Not *all* transactions will be able to match the
> wildcard. For instance if someone sent some crazy smart contract tx to
> your address, the script associated with that tx will be such that it
> will not apply to the wildcard. Most "vanilla" utxos that I've seen
> have the formula: OP_DUP OP_HASH160 [a hash corresponding to your
> address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could
> apply to the wildcard.
>
> On 11/24/15, Dave Scotese via bitcoin-dev
>  wrote:
> > What is required to spend bitcoin is that input be provided to the UTXO
> > script that causes it to return true.  What Chris is proposing breaks the
> > programmatic nature of the requirement, replacing it with a requirement
> > that the secret be known.  Granted, the secret is the only requirement in
> > most cases, but there is no built-in assumption that the script always
> > requires only that secret.
> >
> > This idea could be applied by having the wildcard signature apply to all
> > UTXOs that are of a standard form and paid to a particular address, and
> be
> > a signature of some kind of message to that effect.  I imagine the cost
> of
> > re-scanning the UTXO set to find them all would justify a special extra
> > mining fee for any transaction that used this opcode.
> >
> > Please be blunt about any of my own misunderstandings that this email
> makes
> > clear.
> >
> > On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
> >> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >>> **OP_CHECKWILDCARDSIGVERIFY**
> >>
> >>
> >> Some (minor) discussion of this idea in -wizards earlier today starting
> >> near near "09:50" (apologies for having no anchor links):
> >> http://gnusha.org/bitcoin-wizards/2015-11-24.log
> >>
> >> - Bryan
> >> http://heybryan.org/
> >> 1 512 203 0507
> >>
> >> ___
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >>
> >
> >
> > --
> > I like to provide some work at no charge to prove my value. Do you need a
> > techie?
> > I own Litmocracy  and Meme Racing
> >  (in alpha).
> > I'm the webmaster for The Voluntaryist 
> which
> > now accepts Bitcoin.
> > I also code for The Dollar Vigilante .
> > "He ought to find it more profitable to play by the rules" - Satoshi
> > Nakamoto
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev