> Considering the website example, where most websites uses static content, a bitcoin address could accumulate a dozen of transactions before the webmaster changes the address to a new one. Would this use case be a better match for something such as stealth addresses or hierarchical deterministic addresses? Trevin Hofmann On Nov 25, 2015 8:16 AM, "Erik via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Nice idea. I see it as an important feature because of several reasons: > > Considering the website example, where most websites uses static > content, a bitcoin address could accumulate a dozen of transactions > before the webmaster changes the address to a new one. > > Also consider a QR-code address printed on paper. That address is also > prone to multiple payments, which could be several small ones. > > You ask someone to pay an amount of BTC. That person would be someone > that want you to actually don't get any money at all, so instead of > sending one payment, the person sends a lot of small TXes. It costs a > lot more to achieve this, but that doesn't bother the person sending the > transactions. What you see is the transactions to the address you've > agreed sum up to the amount you asked for. When you later try to spend > it, you can't because of that the size of all UXTOs is too high to even > overcome the tx fee. > > If you use a wildcard transaction to bake them together into one UXTO, > you will not need to pay more than just one tx fee to solve the problem > you've got. Also the network will benefit from this because the > alternative is to not spend those UXTOs at all because it costs more > than it earns, leaving lots of UXTOs in the databases. > > Some problems to consider is: > * Which addresses should be involved in a wildcard TX. > * How to not make it repeatable or delayed so that UXTOs not intended to > be in that TX wouldn't be included. > * How to make it impossible to sign an wildcard TX with a future date. > * How to limit outputs so they not are in risk being double-spent. > * How to guarantee that the output is actually calculated from all the > inputs involved and not less, making insane TX fees available. > > I could see possible solutions to this problems: > * Using the highest block height number of transactions to include or > maybe better, the UXTO of one transaction destined to that address > involved in that block - that implies collecting all UXTOs in that block. > * Using a signature that includes the date. To let it be present more > times in the blockchain requires another timestamp that is newer than a > wildcard TX already existing in the blockchain. Also make the > transaction invalid to put in a block if the timestamp is behind a > certain time or in the future. > * Using the coinbase UXTO or the block hash from the latest block as > proof that the transaction isn't created earlier than that. Also makes > the wildcard TX invalid if that block isn't part of the blockchain > anymore. This also have a secondary effect of certifying the blockchain > itself making it more difficult to fork it from far behind because it > will effectively remove all transactions depending on a UXTO including > this type of certification. > * Either using a priority like way to determine what are being left to > wildcard in a block - all transactions spending UXTOs of that address is > removed before the wildcard TX if they occurs in the same block. Either > it is possible to set a rule that if a wildcard TX exists in one block, > it is invalid to include other UXTOs that is to be be included in the > wildcard from the same address in the same block. (Classic > double-spending rule) > * Using a special form of output specifying only one destination > address/script and the amount of fees to pay. If the amount of fees > could be payed, then the rest will be sent to the destination address. > This covers intentional delaying and also discourage forking the > blockchain by miners to making the signature UXTO appear later than more > recent transaction in a new fork to collect the later txes as fee. > > This transaction type would in fact look like a time-limited offer to > the network to reduce the UXTO set of an address. I guess some miners > will then use a logic that prefers this types of TXes even if they are > low-fee because, if they removes lots of UXTOs, they benefits the network. > > Sincerely, > Erik. > > Den 2015-11-25 kl. 02:26, skrev Chris Priest via bitcoin-dev: > > 1. Technically is it promoting address reuse, but in this case, I > > think it's OK. The primary purpose of a coalescing transaction is to > > clear out *all* funds associated with one address and send them to > > another address (belonging to the same owner). If you coalesce the > > inputs to the same address over and over again, you an do that, but > > you'll run the risk of leaking your private key. > > > > 2. I see these transactions being broadcast in the background when the > > user is not planning on sending or receiving any payments. By the time > > the wallet user wants to spend funds from the address, the coalescing > > transaction should be sufficiently deep enough in the blockchain to > > avoid re-org tomfoolery. Exchanges and payment processors who take in > > payments around the clock will probably never use these transactions, > > at least not on "live" addresses. > > > > 3. I never thought of that, but thats a benefit too! > > > > On 11/24/15, Jannes Faber via bitcoin-dev > > wrote: > >> 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 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQIcBAEBAgAGBQJWVcKuAAoJEJ51csApon2ofiYP/15DXthFvNg9pBPOaaboGOh1 > DhN7R3SXnt4PTLygQGO3AkTRcDinQrZ0Q4GDLIgrOkaKJ4yr6FtnoEYGORQSfFkx > 946eWtqkR4+IJi7gYIIn1yOfFjWKUp9l4OOWBA8Rxsn0tZUAQPXzf2f+dxAaj0Gd > fLrftYvK1XJ8BolhwNfonJ193RJGFynQfWqZ+XeQQMS5LW23RpQLyI26f495MPHG > Wug7M/Aq50JrJDe1OyhjnnjYxNV6Gdbg9o3YIdj2gaOsBKHzsPK+LjcLCdRqD/OI > TBwmwiI4vrOl3HzvtucHxQqnaP43wubydVhPfmjG97tDaj2cVLjadc17e77PzCVI > 8N21oVIWDzyW6y14REoo1Zs4A9ALpHjXAGWdls71eP1NIFcfdFAJWhk2/giisw8o > ZsQTgq2mUHS+n4q3NjFEwGxS011yADE3Uf3ryjuTjp3HVQf3lZxn4E4Z7z/4gkXm > /h/3Ln7PkjEmOqp9htgHcYW7q5goeJzV0xNDBoY9wvOlJQcAh6nTiS4SJEiFJvXU > xVZIGZsisrdW/1CfcszOi7KFGaaV1VlAXQnuJHj1I3dJ2r68yi5TQk6voMNFprEz > 2R4zuZKjIoH79rOjDV8l6XBIU1Kh92GEzCFlTicfvnAoa853fGZt+V/77ralftJW > E6sERK8uG8S3KdBSVQ7K > =1xdi > -----END PGP SIGNATURE----- > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >