Re: [Bitcoin-development] ASIC-proof mining

[kjj]

Just some general comments on this topic/discussion.

I suspect that there exist no algorithms which cannot be done better in 
an application-specific device than in a general purpose computer.  And 
if there is such a thing, then it must necessarily perform best on one 
specific platform, making that platform the de facto application 
specific device.

I'm not sure how one would go about proving or disproving that, but it 
seems very likely to be true.

IO-bound is exactly the same as memory bound, for devices that have 
enough memory.  20 GB is already trivial today, and you don't really get 
into ask-the-wife-for-permission money until you cross 128 GB. The 
exception would be if the IO was to an oracle outside of the device's 
control, and artificially limited in throughput.  Such a centralized 
oracle would be contrary to the goals usually stated by people thinking 
about anti-ASIC designs, so there isn't much point.

Keeping the algorithm simple, and ASIC-easy, has one other advantage.  
Just about anyone can sit down and design an ASIC for SHA, for example, 
leading to diversity in the marketplace.  A harder algorithm can still 
be made into an ASIC (or more generally into an ASD), but will require 
more skilled designers, more expensive fabrication, etc.  This actually 
concentrates the ASIC advantage into the hands of fewer people, which 
again, is contrary to the stated goals.

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

[kjj]

The HTTP status code system seems to work well enough, and seems to give 
the best of both worlds.  A 3 digit numeric code that is 
machine-readable, and a freeform text note for humans.

The clever part about that system was in realizing that the numeric 
codes didn't need to account for every possible error. They just need to 
give the other node the most useful information, like "try that again 
later, I'm having a temporary problem" vs. "That is just plain wrong and 
it will still be wrong next time too, so don't bother to retry".

We can leave it to the humans to puzzle out the meaning of "403: values 
of txid gives rise to dom!"

Gavin wrote:
>
> On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman  
> wrote:
>
>> Would it make sense to use either fixed length strings or maybe even enums?
> No. Enums or fixed length strings just make it harder to extend, for no 
> benefit (bandwidth of 'reject' messages doesn't matter, they will be rare and 
> are not relayed).
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

[kjj]

Any reason not to use actual HTTP codes?  I'm not aware of any major 
deficiency in them.  Most of them won't apply to us, which is fine, they 
don't seem to apply to HTTP either.  We can extend the scheme on our own 
if we find a good reason to.


That implies 16 bits, or a varint.  I would avoid a string or varstring 
here; we already have a text field.  Varint vs. 16 bits is a minor 
issue, and arguments can be made in both directions.  I flipped a coin 
and got heads, so I'll say varint.


Gavin Andresen wrote:

RE: use HTTP-like status codes:

Okey dokey, I'll add a one-byte machine-readable HTTP-like status 
code. Unless y'all want a 32-bit status code.  Or maybe a varint. Or a 
three-character numeric string. I really and truly don't care, but I 
am writing this code right now so whatever you want, decide quickly.


If anybody has strong feelings about what the reject categories should 
be, then please take the time to write a specific list, I can't read 
your mind



--
--
Gavin Andresen


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk


___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] we can all relax now

[kjj]

One of the things that really gets me going is when someone devises a 
model, tests it against itself, and then pretends that they've learned 
something about the real world.

Naturally, the Selfish Mining paper is exactly this sort of nonsense.  
Their model is one with no latency, and one where the attacker has total 
visibility across the network.  An iterated FSM is not a suitable 
simulation of the bitcoin system.  The bitcoin network does not have 
states, and to the extent that you can pretend that we do, you can't 
simulate transitions between them with static probabilities.

The authors understand this deep down inside, even though they didn't 
work out the implications.  They handwave the issue by assuming a total 
sybil attack, and in true academic spirit, they don't realize that the 
condition necessary for the attack is far, far worse than the attack itself.

Greg said he'd like to run some simulations, and I'm thinking about it 
too.  Unfortunately, he is busy all week, and I'm lazy (and also busy 
for most of tomorrow).

If neither of us get to it first, I'm willing to pitch in 1 BTC as a 
bounty for building a general bitcoin network simulator framework. The 
simulator should be able to account for latency between nodes, and 
ideally within a node.  It needs to be able to simulate an attacker that 
owns varying fractions of the network, and make decisions based only on 
what the attacker actually knows.  It needs to be able to simulate this 
"attack" and should be generic enough to be easily modified for other 
crazy schemes.

(Bounty offer is serious, but expires in one year [based on the earliest 
timestamp that my mail server puts on this email], and /may/ be subject 
to change if the price on any reputable exchange breaks 1000 USD per BTC 
in that period.)

Basically, the lack of a decent network simulator is what allowed this 
paper to get press.  If the author had been able to see the importance 
of the stuff he was ignoring, we wouldn't be wasting so much time 
correcting him (and sadly the reporters that have no way to check his 
claims).

https://bitcointalk.org/index.php?topic=324413.msg3495663#msg3495663



--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Floating fees and SPV clients

[kjj]

After reading all 99 messages in this thread, I think allowfee is just 
about perfect.


It effectively lets merchants to give an allowance against the purchase 
price for network fees, if they choose.  It is still up to the sender 
(and/or the sender's software) to get the fees right.  Sometimes the 
sender will need to pay more fees than allowed, and sometimes the sender 
will need to pay less.


We can't solve the fee problem, in general.  I'm not sure that we can 
even define it properly.  But this is something that we can do, that 
will be useful at least occasionally, and that will cause no harm the 
rest of the time.


P.S.  Clever senders can use this to defrag their wallets.  Who wants to 
write the patch for that?


Gavin Andresen wrote:
On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn > wrote:


PPv1 doesn't have any notion of fee unfortunately. I suppose it
could be added easily, but we also need to launch the existing
feature set.


Lets bang out a merchant-pays-fee extension.

How about:

SPEC:

optional uint64 allowfeetag number=1000

Allow up to allowfee satoshis to be deducted from the amount paid to 
be used to pay Bitcoin network transaction fees. A wallet 
implementation must not reduce the amount paid for fees more than 
allowfee, and transaction fees must be equal to or greater than the 
amount reduced.


:ENDSPEC

Rationale: we don't want wallet software giving users discounts-- 
sending transactions that are amount-allowfee without paying any fee. 
 We also want to allow users to pay MORE in fees, if they need to 
(fragmented wallet, maybe, or big CoinJoin transaction) or decide to.



PS: I think there was also consensus that the BIP72  request=...   
should be shortened to just r=... (save 6 chars in QR codes).  Unless 
somebody objects, I'll change the BIP and the reference implementation 
code to make it so...


--
--
Gavin Andresen



--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk


___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Monetary Authority for Bitcoin

[kjj]

Ryan Carboni wrote:


Bitcoin lacks a Central Bank.


This is a feature, not a bug.

Also, this is offtopic.  Political debate is thataway ->.

bitcoin-development is for development and technical discussion.
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin-development Digest, Vol 31, Issue 25

[kjj]

Ryan Carboni wrote:
And the economic parameters of bitcoin are not fixed in stone. If 
there needs to be a change, it will be messy but it could happen.


Need is an awfully big word.  One thing we are certain of is that some 
guy telling us all that we are wrong is nowhere near the "need" level.
Besides, using Austrian precepts of inflation blurs the fact that 
deflation will still be possible under my proposal. Although amusingly 
enough Austrian-defined inflation is still occurring within Bitcoin, 
in fact faster then desired since blocks are being processed every 
seven minutes now as opposed to ten, and it's quite likely when 28nm 
ASIC miners are released that blocks will be processed every five 
minutes before the difficulty is adjusted again.
Don't take this the wrong way, but things like this make it very hard 
for us to take you seriously.


Please read up on how the system works, then read up on why we reject 
the argument from authority, then if you still have something to say, 
please do so in a proper venue.  One option for this discussion is the 
bitcointalk.org forums, where you will find literally dozens of threads 
proposing the exact same thing you are proposing.


This mailing list is NOT for political discussion.
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Multisign payment protocol?

[kjj]

I was trying to use bip10 for multisig and coinjoin, but there was a 
problem with it.  I'll have to look back at my notes, but I thought I 
sent you a message about it. And then real life swallowed my bitcoin time...


I think the bottom line was that it would be useful in the generic case 
with just one minor change.  If there is interest, and it sounds like 
there just may be, I can dust off my notes and see where I left it.  
Probably should do it soon before someone implements it in PB or XML.


Alan Reiner wrote:
Then of course I tried to do this with BIP 10 
 when 
Armory implemented offline-transactions two years ago.  I got some 
positive feedback, but no one wanted to help improve it, etc.  I guess 
nobody else was doing it and/or cared at the time.  So I continue to 
use BIP 10 even though it's pretty crappy.  I wanted it to be useful 
for multisig, too, but it has some deficiencies there (it was done 
when Armory was extremely young and OP_EVAL was still on the table).


However, with all this activity, we should start thinking about that 
and discussing it.  Otherwise, I'll just do my own thing again and 
probably end up with something that fits my own needs, but not anyone 
else's.  Really though, multisig shouldn't require all the same app to 
work.


-Alan


On 03/10/2014 01:49 PM, Gavin Andresen wrote:

In my experience, best process for standardizing something is:

1) Somebody has a great idea
2) They implement it
3) Everybody agrees, "Great idea!" and they copy it.
4) Idea gets refined by the people copying it.
5) It gets standardized.

Mutisig wallets are at step 2 right now. BIP is step 5, in my humble 
opinion...





On Mon, Mar 10, 2014 at 1:39 PM, Drak > wrote:


I was wondering if there would be merit in a kind of BIP for a
payment protocol using multisig?

Currently, setting up a multisig is quite a feat. Users have to
exchange public keys, work out how to get the public keys from
their addresses. If one of the parties are not savvy enough, an
malicious party could easily be setup that was 2 of 3 instead of
2 of 2 where the malicious party generates the multisig
address+script and thus be able to run off with funds anyway.

It's also terribly complex to generate and keep track of. There's
been a nice attempt at creating an browser interface at
coinb.in/multisig  but it still lacks
the kind of ease with created by the payment protocol. If there
was a BIP then it would go a long way to aiding future usability
of multisig wallet implementations.

What are your thoughts?

Drak


--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases
and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
--
Gavin Andresen


--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech


___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech


___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-de

Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

[kjj]

Troy Benjegerdes wrote:
> Mark Friedenbach wrote:
>> Bitcoin is not a centralized system, and neither is its development. I
>> don't even know how to respond to that. Bringing up altchains is a total
>> red herring.
>>
>> This is *bitcoin*-development. Please don't make it have to become a
>> moderated mailing list.
> When I can pick up a miner at Best Buy and pay it off in 9 months I'll
> agree with you that bitcoin *might* be decentralized. Maybe there's a
> chance this *will* happen eventually, but right now we have a couple of
> mining cartels that control most of the hashrate.
>
> There are plenty of interesting alt-hash-chains for which mass produced,
> general purpose (or gpgpu-purpose) hardware exists and is in high volume
> mass production.
Decentralized doesn't mean "everyone is doing it", it means "no one can 
stop you from doing it".  Observe bitcoin development.  A few people do 
the bulk of the work, a bunch more people (like me) do work ranging from 
minor to trivial, and millions do nothing.  And yet, it is still totally 
decentralized because no one can stop anyone from making whatever 
changes they want.

So it is also with mining.  The world overall may make it impractical, 
perhaps even foolish, for you to fire up your CPU and mine solo, but no 
one is stopping you, and more to the point, no one is capable of 
stopping you.  There is no center from which you must ask permission.

On moderation, I note that moderation can also be done in a 
decentralized fashion.  I offer this long overdue example:

:0
* ^From.*ho...@hozed.org
/dev/null

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

[kjj]

Matt Whitlock wrote:
> The creation date in your BIP header has the wrong format. It should be 
> 01-04-2014, per BIP 1.
>
At first, I thought this was a second April Fool's joke, but then I 
looked and saw that all of the BIPs really do use this format.  As far 
as I can tell, we are using this insane format because RFC 822 predates 
ISO 8601 by half a decade.

Since we don't have half a gajillion mail servers to patch, we could, if 
we desired, adopt a sensible date format here.  The cost to the 
community would be minimal, with probably not more than a half dozen 
people needing to update scripts.  It could even be as simple as one guy 
running sed s/parseabomination/parsedate/g

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[kjj]

Multi-sig requires infrastructure.  It isn't a magic wand that we can 
wave to make everyone secure.  The protocols and techniques necessary 
don't exist yet, and apparently no one has much of an incentive to 
create them.

I mean no offense, and I don't mean to pick on you.  Your post stuck out 
while I was reading.  Secure multi-sig is what we all want, but wanting 
apparently isn't enough to make it happen.

Other random notes from reading this 50+ post thread:

Perhaps we should have a config flag to prevent a node from serving IBD 
to new nodes.  IBD crushes marginal machines, particularly those with 
spinning disks.  This has been extensively discussed elsewhere.

The ideal IBD hosts are serving the blockchain out of a RAM disk. Is 
there any interest in setting up a network of volunteers to host 
expensive servers with fast connections?  It doesn't look too terribly 
difficult to figure out when a node has stopped asking for blocks in 
bulk, so we could add another config flag to eject nodes once they are 
done booting.

Even ignoring IBD, I think that we are gradually outgrowing cheapass 
hosting options.  Personally, I long ago gave up on answering forum 
questions about running nodes on virtual servers and VPSs.  It is 
certainly still possible to run bitcoind on small boxes, but it isn't 
trivial any more.  (Anyone running on less than my Athlon XP 1800+ with 
896 MB RAM?)  If we want those nodes back, we need to optimize the hell 
out of the memory use, and even that might not be enough.


Eric Martindale wrote:
>
> We need to make it so mind-numbingly simple to "run Bitcoin correctly" 
> that the average user doesn't find reasons to do so in the course of 
> normal use.  Right now, Coinbase and Bitstamp are winning in the user 
> experience battle, which technically endanger the user, and by proxy 
> the Bitcoin network.
>
> Multi-sig as a default is a start.  It won't succeed unless the user 
> experience is simply better than trusted third parties, but we need to 
> start the education process with the very basic fundamental: trusting 
> a third-party with full access to your Bitcoin is just replacing one 
> centralized banking system with another.
>
>


--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Difficulty adjustment / time issues

[kjj]

Gavin Andresen wrote:
> Background:
>
> Timejacking:
>http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html
>
> And a recent related exploit launched against the low-difficulty
> alternative chains:
>https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772
>
>
> Seems to me there are two fundamental problems:
>
> 1) Bitcoin should be overlapping the ranges of block timestamps that
> it uses to calculate difficulty adjustments.
>
> 2) Bitcoin's "what time is it" code is kind of a hack.
>
>
> Fixing (1) would mean a potential block-chain split; before
> considering doing that I'd like to consider second-best solutions.
>
> Fixing (2) is easier; incorporating a ntp library and/or simply
> removing the bitcoin mining code from the client but requiring pools
> and miners to have accurate-to-within-a-minute system clocks (or their
> blocks will be "discouraged") seems reasonable to me. If you want to
> produce blocks that the rest of the network will accept, run ntp on
> your system.
>
> I THINK that fixing (2) will make (1) a non-issue-- if miners can't
> mess around with block times very much then it will be very difficult
> for them to manipulate the difficulty for their benefit.
>
The first thing I always do when I grab the source for my colo server is 
patch util.cpp so that GetAdjustedTime() returns GetTime() with no 
adjustment.  But I'm the kind of guy that buys special GPS receivers 
because stratum 2 isn't low enough and occasionally checks ebay for 
caesium fountains.

NTP has been around for long enough now that there is no reason for the 
client to screw with the clock.  If the client sees different times on 
the network, it should issue a warning, and if it is off too far, it 
should give an error and fail to run (and/or peers should reject it).

But that doesn't solve the whole problem, because the block timestamp 
checking is based on the assumption that the node is looking at the 
bitcoin clock rather than the, ahem, real clock.  If we change the idea 
of network time to NTP, we will then need to write (and test!) new block 
timestamp rules to account for the new assumptions.

I'm not sure that just fixing item 2 is going to stop the attacks found 
by ArtForz, et al.  Some of the attacks Art pointed out are particularly 
bad because they change the incentive structure of the system, at least 
in the short term.  We need to flip that back around ASAP.

Also, this is going to cause problems for at least one pool operator.

--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the 
BlackBerry® mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry® DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1 
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Request review: drop misbehaving peers

[kjj]

Luke-Jr wrote:
> On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
>> I'm looking for review of this pull request:
>>https://github.com/bitcoin/bitcoin/pull/517
> "Non-standard" transactions, or those with "insufficient" fees should not be
> penalised. These are properly relay/miner policy decisions, not protocol
> violations, and should be made more easily configurable, not punished for
> configuration.
>
>
A few non-standard transactions are probably legitimate.  A whole bunch 
of them are probably not.  I would think that assigning a point or two 
of badness to a peer sending one is pretty reasonable, with the 
understanding that we would need to adjust that as the network evolves.

--
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Request review: drop misbehaving peers

[kjj]

Luke-Jr wrote:
> On Thursday, September 15, 2011 8:56:24 AM kjj wrote:
>> Luke-Jr wrote:
>>> On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
>>>> I'm looking for review of this pull request:
>>>> https://github.com/bitcoin/bitcoin/pull/517
>>> "Non-standard" transactions, or those with "insufficient" fees should not
>>> be penalised. These are properly relay/miner policy decisions, not
>>> protocol violations, and should be made more easily configurable, not
>>> punished for configuration.
>> A few non-standard transactions are probably legitimate.  A whole bunch
>> of them are probably not.  I would think that assigning a point or two
>> of badness to a peer sending one is pretty reasonable, with the
>> understanding that we would need to adjust that as the network evolves.
> No. There is no such thing as "non-standard transactions" really; it is simply
> "transactions outside of the bounds that I as a user/miner will relay/accept".
> It is perfectly legitimate for other users/miners to relay/accept transactions
> more liberally. By penalising for transactions falling outside of your
> *personal policies*, you would end up banning many legitimate nodes.
It is certainly true that standardness is an artificial construct that 
only has meaning to this particular implementation of the software, but 
no meaning in the context of the protocol or the system as a whole.

On the other hand, the vast, vast majority of all transactions follow a 
particular pattern.  If someone gives you one that doesn't match the 
standard pattern, you might be a little suspicious, but it is no big 
deal.  But, if they emit dozens or hundreds, it is hardly unreasonable 
to disconnect them until you figure out what's going on.

--
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Beyond IP transactions: towards a bitcoin payment protocol

[kjj]

Pieter Wuille wrote:
> Hello everyone,
>
> here is an idea i've bean writing up: https://gist.github.com/1237788
>
> I hope it can start some discussion about moving away from static bitcoin 
> addresses
> as descriptions for transactions. I suppose it's a candidate for a 
> BIP/BEPS/BFC/...,
> but as things don't seem to have been decided completely about those, I put 
> it in a
> Gist.
>
> Please, comment.
>
This may just be me, but this really looks like an incredibly convoluted 
way to solve a bunch of problems that aren't really problems.  The 
central issue that I see, is that you assume that there is no out of 
band channel, as if people were just sending transactions to addresses 
that came to them in a dream.

I think that this assumption is only true when it doesn't matter.  For 
example, I have a donation link in my sig on the forums.  I don't care 
much who sends to it, or why, and I certainly don't need annotations or 
a refund address.  The rest of the time, payments are sent to addresses 
that already have sufficient context.

Only one of the advantages listed is actually an advantage.  That is 
that payments to stale addresses can be stopped.  This isn't much of an 
advantage though, as someone blindly sending payments (donations, 
really) to addresses found on backup tapes and web archives without 
verifying that they are still current kinda deserve what they get.  So 
it really only stops payments to services that go defunct the same day 
(more or less).

In the end, I just don't see the value in giving a URL so that I can go 
ask a server for information that could just as easily have been encoded 
in the URL directly.

Then again, I'm cynical, and didn't sleep very well last night.  Maybe 
the next person will think better of it.

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development