Bitcoin Forum
May 17, 2024, 07:12:14 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Why will nodes not relay non-standard txs?  (Read 1583 times)
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
May 08, 2014, 01:15:58 PM
 #21

Out of interest is there a reason for having a single branch-controlling flag for 1/2/3 then doing all this copying and dropping of the flag? Visually it feels simpler if you do something like:

I felt it made it easier to describe.  You could just use a simple template match.

In retrospect, your way is better, since the dups etc require space anyway.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
edmundedgar
Sr. Member
****
Offline Offline

Activity: 352
Merit: 250


https://www.realitykeys.com


View Profile WWW
May 08, 2014, 11:13:14 PM
 #22

You could just use a simple template match.

OK, that's an important consideration. There's not much point in proposing a standard transaction type and trying to persuade the core devs that it's clean and simple and isn't going to blow up anything up if it needs a load of gruesome, potentially buggy code to find out whether a transaction actually matches that type...
edmundedgar
Sr. Member
****
Offline Offline

Activity: 352
Merit: 250


https://www.realitykeys.com


View Profile WWW
May 09, 2014, 03:09:32 AM
 #23

This thread's got me wondering whether, assuming core want to stick with the standard pattern white-list and aren't going to be doing a thorough rethink of the whole thing, there might be a middle way between, "Patch your time-stamper to accept any damn thing" and "Only mine patterns that get permission from core devs, who need to be super-cautious".

If we had a reasonably well-supported patch expanding the standard transaction rules maintained by some generally sensible people, which still used a white-list but was a bit more open about including not-obviously-harmful patterns, are there miners out there apart from Luke-Jr who would be prepared to run it?

Obviously we don't usually want all kinds of weird versions of bitcoin doing their own thing floating around the place, but this seems like a special case where there's no disagreement about what's valid once it's in a block, we already have a decent proportion of hashing power (Eligius) applying its own rules, and you can get all kinds of things into blocks anyhow.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4172
Merit: 8421



View Profile WWW
May 09, 2014, 03:49:16 AM
 #24

This thread's got me wondering whether, assuming core
I want to transition to a blacklist instead: inhibit the no-op opcodes, non-canonical pushes/signatures, oddball versions, and enforce sanity limits on size and checksig count... everything else relayed (assuming it's valid and meets whatever fee criteria is in use). I think this is also the goal of everyone else working on core in some timeframe or another: No one has any great affection for the whitelist approach afaik, it's just expedient and changing this is not a top priority compared to all the things which have a more urgent need.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!